|
|
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
hi all Есть ФБ, собран из сегодняшних сырцов. Есть пустая база с FW = OFF, page_size=4096. И есть вот такой скрипт, который сечас выполняется: (создаёт SP, таблицы + индексы, затем стартует select * from SP for update) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. Пример вывода этого скрипта: Код: plaintext 1. 2. 3. 4. Параллельно с этим, в отдельном окне пляшет iostat с логированием своего вывода в файлик. Данные в iostat'e обновляются каждую секунду. Скачок в 10 сек, как видим, был в 19:05:50. Значит, можно глянуть в лог iostat'a за период с 19:05:20 по 19:06:20 и попытаться понять, чем был вызван этот тупняк. Фрагмент этого лога - в аттаче. Поможыте понять, кто в линухе силён: на что обратить внимание ? В упор не вижу, чем период 19:05:40...19:05:50 отличается от остальных: %iowait везде примерно одинаковый, на уровне 6...8%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.01.2014, 19:26:35 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
"Продолжаем разговор" (С) :) Через 12 ч после начала теста вывод execute block'a состоит сплошняком из "перлов": Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. То есть, 10'000 строк в TDETL + 1 строка в TMAIN добавляются то 8, а то и 80 сек. Пик был (пока что) в 07:31:51 и составил 6 минут 46 сек %-) Чем его объяснить - то тайна велика есмь Ибо логи iostat и vmstat за этот временн о й отрезок (почти 7 минут) - ничего выдающегося не содержат, если сравнивать их показатели с другим временем. Кому интересно - посмотрите в аттач, там два фрагмента этих логов, с 07:24:43 по 07:32:00. Насколько могу понять, IO "пишет себе и пишет", не больше и не меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 10:19:05 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
FW-OFF? P.S. Топик не читал. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 10:45:20 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
авторЕсть ФБ, собран из сегодняшних сырцов. Есть пустая база с FW = OFF , page_size=4096. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 10:55:58 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, что мешает выставить MaxUnflushed* и посмотреть, не исчезнут ли "затыки"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 10:58:47 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Вообще-то говоря, состояние базы в момент, когда тест закончится, у мну есть, т.к. сейчас идёт второй "забег". Вот оно: gstat -r Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. Когда база пустая, то статистика добавления 100 строк в TMAIN и 10000 строк в TDETL следующая: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Когда же таблица TMAIN содержит 2 млн, а TDETL - 200 млн строк, то коленкор таков: Код: plaintext 1. 2. 3. 4. 5. 6. 7. (время вполнения намеренно выкинул, т.к. оно всё время "скачет" - см пост выше, 15400933 ). Я понимаю, что там random IO из-за поиска места в индексах для вставки ключей - но всё-таки число фетчей только в полтора раза выше прежнего (363208 / 232208). На что время-то уходит такое (по нескольку минут!) при работе только ОДНОГО аттача ? ЗЫ. На хосте ничего больше, кроме ФБ, не молотит. Только рядом скрипты с линуховым мониторингом: iostat, vmstat (сейчас вот еще iotop lобавил). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:10:45 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrчто мешает выставить MaxUnflushed* и посмотреть, не исчезнут ли "затыки"?пардон, не увидел этот пост вовремя. Сейчас уже буду ждать окончания молотьбы, там дошло аж до 180 млн: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Правильно ли я понимать, что оба maxUnflushed* надо просто выставить в какие-то большие числа ? (например, maxUnflushedWrites = 2048M) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:14:33 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидЯ понимаю, что там random IO из-за поиска места в индексах для вставки ключей - но всё-таки число фетчей только в полтора раза выше прежнего (363208 / 232208). а глубина индексов в 4 и даже 5 уровней тебя не смущает? Сотни миллионов записей на базе со страницей 4КБ - это садомазохизм такой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:19:09 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидПравильно ли я понимать, что оба maxUnflushed* надо просто выставить в какие-то большие числа ? (например, maxUnflushedWrites = 2048M) боже ты мой, конечно неправильно. Спровоцируй регулярный частый сброс файлового кеша, чтобы оно не накапливалось. Правда, если ты все 200млн вливаешь в одной транзакции, то эта настройка тебе не поможет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:23:05 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидЯ понимаю, что там random IO из-за поиска места в индексах для вставки ключей - но всё-таки число фетчей только в полтора раза выше прежнего (363208 / 232208).а глубина индексов в 4 и даже 5 уровней тебя не смущает? Сотни миллионов записей на базе со страницей 4КБ - это садомазохизм такой?1. Индексы такой глубины - это приговор на "вечные тормоза" ? Если да, то чем это объяснить, почему на глубине 3 всё пучком, а 5 -уже "куку" ? Затратами на расщепление листовых страниц и всех вышележащих уровней или еще чем-то ? 2. Страница 4К - это только первая фаза нашей эстафеты Дальше надо будет на 8 и 16 К проверить. Таково "задание Партии". Кста! А ведь тут не раз проскакивала мантра: "большая страница - хорошо для выборок, но плохо для ДМЛ"... Ну так у мну страница, как раз "хорошая" по размеру для DML, нет разве ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:34:13 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидПравильно ли я понимать, что оба maxUnflushed* надо просто выставить в какие-то большие числа ? (например, maxUnflushedWrites = 2048M)боже ты мой, конечно неправильно. Спровоцируй регулярный частый сброс файлового кеша, чтобы оно не накапливалось. Правда, если ты все 200млн вливаешь в одной транзакции, то эта настройка тебе не поможет...Дык не вопрос, могу сделать всё в цикле, чтобы там автономная транзакция запихивала по 10 тыс в tmain + 1 млн в tdetl. Только ты скажи всё-таки: какие значения поставить для maxUnflushed* ? А то опять пальцем в небо ткну и время потеряю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 11:36:47 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоидтут не раз проскакивала мантра: "большая страница - хорошо для выборок, но плохо для ДМЛ"... Ну так у мну страница, как раз "хорошая" по размеру для DML, нет разве ? это правда для вменяемых размеров базы, когда глубина индексов не зашкаливает. Иначе ахтунг в индексах очень быстро перевешивает все остальные критерии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:14:31 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоидне вопрос, могу сделать всё в цикле, чтобы там автономная транзакция запихивала по 10 тыс в tmain + 1 млн в tdetl. Только ты скажи всё-таки: какие значения поставить для maxUnflushed* ? А то опять пальцем в небо ткну и время потеряю. попробуй настроить на коммит не реже чем раз в 1 млн записей, лучше меньше. Т.е. я бы предложил порции в 1К / tmain + 100К / tdetl, при этом 1 <= MaxUnflushedWrites <= 10 (он в коммитах измеряется). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:18:33 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrэто правда для вменяемых размеров базы, когда глубина индексов не зашкаливает. Иначе ахтунг в индексах очень быстро перевешивает все остальные критерии.А что именно там "ахтунгом" является ? Ну, вот есть индекс глубиной = 5 - и что в нём "такого страшного", отчего конкретно идут тормоза при добавлении ключей ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:22:47 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидне вопрос, могу сделать всё в цикле, чтобы там автономная транзакция запихивала по 10 тыс в tmain + 1 млн в tdetl. Только ты скажи всё-таки: какие значения поставить для maxUnflushed* ? А то опять пальцем в небо ткну и время потеряю. попробуй настроить на коммит не реже чем раз в 1 млн записей, лучше меньше. Т.е. я бы предложил порции в 1К / tmain + 100К / tdetl, при этом 1 <= MaxUnflushedWrites <= 10 (он в коммитах измеряется).А вот этому: Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:25:39 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, MaxUnflushedWriteTime не трогай ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2014, 12:28:57 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrпопробуй настроить на коммит не реже чем раз в 1 млн записей, лучше меньше. Т.е. я бы предложил порции в 1К / tmain + 100К / tdetl, при этом 1 <= MaxUnflushedWrites <= 10 (он в коммитах измеряется).Ффух... запустил, вобщем. И кажется мну, что очень скоро придется рестартовать с другим значением MaxUnflushedWrites Вот скрипт: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. Этот скрипт делает в одной автономной транзакции n_insa = 1000 вставок в TMAIN и n_insa * n_detl int = 100'000 вставок в TDETL. Параметр MaxUnflushedWrites установил равным 5. Число буферов - дефолтное, 2048. Параллельно в "мониторных" окнах запущены с логированием: iostat -x; iotop; vmstat. И хотя скрипт только-только начал работать, траблы повторяются (вернее, начались еще раньше, чем прежде): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Метод тыка какой-то идёт %-/ PS. Хреново, что трейс для такого скрипта вообще ничего не показывает: ХП для него деревянный ящик. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 00:34:54 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, вроде была идея сделать некую системную функцию которая могла бы писать в трейс пользовательские сообщения из PSQL. Это могло бы в ряде случаев упростить отладку. Но почему-то от неё отказались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 08:57:56 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, а что в трейсе в моменты 00:25:18 и 00:32:20? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:09:02 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
В общем, докладаю. Затыки идут не только от ожидания сброса файлового кеша на диск (как я понимаю, linux-процессами flush и jdb2). Они возникают при любом MaxUnfluhedWrites, при передаче данных из кеша ФБ в кеш операционки: так показывает iotop . Логи iostat'a и vmstat'a для периодов, когда шли затыки, часто не содержат никаких "особых" значений, указывающих на повышенный IO, поэтому они тут не приводятся. Тест был такой (для maxUnflushedWrites=10): 1. в окнах 1..3 запускаются линух-мониторные утилиты с логированием вывода в соотв. файлы: iostat, vmstat, iotop Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 2. В окне 4 запускается скрипт huge_fil_at.sh ( '_at' = 'autonomous transaction': добавляет пачки записей в автономной транзакции), вызывающий isql и натравливающий на него .sql с заполнением данными. Особенность .sh в том, что по окончании работы isql он будет убивать мониторные процессы, запущенные в окнах 1...3. А сам же isql прекратится по эксепшену, как только время, затраченное на ввод 1'000 записей в TMAIN и 100'000 записей в TDETL, превысит порог = 15'000 ms (переменная 'MS_FOR_STOP'): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Ну, и собственно .sql-скрипт: huge_fil_at.sql Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. В итоге всех прогонов (при ЛЮБОМ maxUnflushedWrites), всё заканчивалось примерно вот так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Как видим, последние два затыка были = 12 и 16 сек. Для затыка-1 лог iotop'a: iotop -o, 08:42:00...08:42:12 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. Для затыка-2 лог iotop'a: iotop -o, 08:43:48...08:44:04 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. Как видно по логам, при затыках 1) всегда что-то делалось потоком 26261 процесса firebird (это CACHE_WRITER ?) 2) иногда включался процесс jbd2/sda4-8. Для информации снял три бактрассы с ФБ (с интервалом ~45 сек) - они в аттаче. ЗЫ. файл базы при последнем затыке имел размер = 1.3 Гб. Его копирование занимает: 1) сразу после теста, когда база торчит в файловом кеше: Код: plaintext 1. 2. 3. 4. 2) при очистке файлового кеша: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:40:33 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
dimitrа что в трейсе в моменты 00:25:18 и 00:32:20?не увидел этот вопрос вовремя, сейчас заново запущу, покажу результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:41:35 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Запустил еще раз этот тест, старушка мучалась около 2 минут. В аттаче логи: 1) трейса 2) вывода isql 3) iotop -o ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:53:36 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
а это... меня сейчас снова побьют за дурацкий вопрос, конечно, но... можно ли "распараллелить" работу передачи страниц в кеш операционки ? ну, то есть несколько cache_writer'ов запустить ? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 09:57:32 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, нафига? Я так понял cache_write как раз делает запись в кэш при этом сериализует и синхронизирует необходимые действия (это собственно и есть общий кэш). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 10:04:21 |
|
||
|
Как сопоставить результаты iostat -x и скачок длительности записи в базу пачки строк ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидЗапустил еще раз этот тест самые тяжелые случаи явно коррелируют: 2014-01-13T 09:44:32 .5470 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION /var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1) /opt/fb30trnk/bin/isql:27569 (TRA_61, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE) 3586 ms , 1 read(s), 1390 write(s), 1 fetch(es), 1 mark(s) 2014-01-13T 09:46:05 .9480 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION /var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1) /opt/fb30trnk/bin/isql:27569 (TRA_72, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE) 7399 ms , 1 read(s), 1176 write(s), 1 fetch(es), 1 mark(s) 2014-01-13T 09:47:48 .0370 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION /var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1) /opt/fb30trnk/bin/isql:27569 (TRA_83, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE) 11548 ms , 1 read(s), 1142 write(s), 1 fetch(es), 1 mark(s) 2014-01-13T 09:49:39 .2420 (25802:0x7f4d6a34d188) COMMIT_TRANSACTION /var/db/fb30/huge_noext_at.fdb (ATT_8, SYSDBA:NONE, NONE, TCPv4:127.0.0.1) /opt/fb30trnk/bin/isql:27569 (TRA_94, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE) 16435 ms , 1 read(s), 1126 write(s), 1 fetch(es), 1 mark(s) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.01.2014, 10:17:19 |
|
||
|
|

start [/forum/topic.php?fid=40&msg=38522475&tid=1563982]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
215ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 231ms |
| total: | 553ms |

| 0 / 0 |
