|
|
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Intro. Эта загадочная история началась почти год назад. Несколько раз в месяц, а затем всё чаще и чаще, юзера начали вопить: дескать, запускаем прогу, а она застревает в самом начале и возобновляет процесс загрузки только через 20-30 сек, а иногда и дольше. Ожесточённая перестрелка Интенсивная переписка с Главным Источником Света, тестирование и накатывание нескольких патчей избавило нас в итоге от этой напасти. По крайне мерее - в продакшене. А заодно родился небольшой shell-скрипт, названный "калибратором", который в цикле делает коннекты и регистрирует их длительность, если она превысила 1 сек. А для сверхтупых коннектов (> 10 сек) еще и строит стек-трейсы. подробнее про этот скрипт1) кладёт в текстовый файл (его имя = 'connect_calibr.txt') значение системного времени, с точностью до ms; 2) вызывает (асинхронно) isql с указанием выполнить некоторую процедуру (её имя = sys_connect_calibrate), после чего делает ПАУЗУ в 10 сек (её смысл - см ниже, пункт 4.1). 3) процедура эта лезет в 'connect_calibr.txt' (он объявлен в базе как external-таблица и считывает оттуда время, которое было непосредственно перед вызовом isql. И сравнивает значение datediff(millisecond from <connect_calibr.txt> to <'now'>) с порогом в 1000 мс. Если значение превысило этот порог, то процедура пишет этот результат (вызова datediff()) в еще один файлик, его имя = 'too_long_connect.txt'. Затем происходит выход из isql. 4) скрипт калибратора по окончании паузы в 10 сек: 4.1) проверяет, остался ли живой процесс isql. Если да, то это значит, что коннект ДО СИХ ПОР не может установиться (за 10 сек!) и тогда калибратор вызывает создание стек-трейса для двух процессов: сервера firebird и застрявшего isql. Результаты gdb складываются в отдельные логи, ес-сно. 4.2) проверяет наличие файла 'too_long_connect.txt' (он заботливо грохает его каждый раз на шаге "1"). Если файл появился, значит коннект шел "странно долго", и это дело регистрируется в логе работы скрипта примерно так: Код: plaintext Обнаружено две закономерности: 1) тормоза при установке коннектов всегда приходят внезапно. То есть, на итерации непосредственном перед "этим" коннект ставился менее чем за 1 сек, а на следующей итерации он вдруг заткнулся на 3-4 сек, а то и больше; 2) чем дольше работает тест с молотилками (и калибратор тоже), тем чаще встречаются затыки и, главное, тем они здоровее. Возможно, dimitr увидел еще что-то (у него есть этот тест и он воспроизвёл эти тормоза). Я не педалирую эту проблему, т.к. Источникам Света сейчас совсем не до этого. Да и чтобы получить сей эффект, нужно и железо подходящее, и запас терпения часов на 20-30 (ладно, шутю: часов на 10-12 :)). Однако, топег всё таки открою. Т.к. стало видно хоть что-то, кроме верхушки айсберга. Handshaking. Источник Света, подаривший миру плагины подключений к ФБ, показал способ "визуализации" процесса установки соединения. На консоли сервера (если он запущен как приложение, а не демон) результат успешного коннекта при этом отображается так: Код: plaintext 1. 2. 3. 4. 5. 6. Когда коннекты прут со 100500 окон, то на консоли сервера будет винегрет из практически одинаковых сообщений, показанных выше. А на консоли isql, который от собранного "по-хитрому" ФБ, процесс установки коннекта виден без всяких "помех". И при успехе он таков: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Анализ логов. Не буду сейчас грузить почтеннейшую публику, ибо поздний час, да и выходной день. Поэтому говорю сразу: заклинивает между строками, которые выделены цветом (см выше) . Каждый раз - именно между этими двумя строками: Код: plaintext 1. Иллюстрация (для любознательных) Вот TOP-3 тупых коннекта, которые у мну зарегистрированы за последние 8 часов (тест стартовал в 16 мск): Код: plaintext 1. 2. Лог работы калибратора для 7195 ms (сообщения "визуализации handshaking'a" показаны синим цветом, штатный вывод в isql - серым, вывод в bash'e - чёрным): Код: 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. Код: 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. Код: 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. В общем - следите за новостями. Наверняка что-нибудь еще нарыть получится. Как знать - вдруг теперь dimitr/hvlad/alex прибьют наконец-то эту багу. Или меня... ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 00:28:53 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
ТаблоидВозможно, dimitr увидел еще что-то (у него есть этот тест и он воспроизвёл эти тормоза). Только на этой неделе он занёс в трекер два тикета, связанных с конектом. Подождал бы ты пока он их закроет... Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 00:39:21 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovТаблоидВозможно, dimitr увидел еще что-то (у него есть этот тест и он воспроизвёл эти тормоза). Только на этой неделе он занёс в трекер два тикета, связанных с конектом. Подождал бы ты пока он их закроет...как их увидеть, только чтобы не заглядывая в фб-девел ? Вот тута: http://tracker.firebirdsql.org/secure/IssueNavigator.jspa?sorter/field=updated&sorter/order=DESC - какие-то обрывки только :-/ Да и здесь: http://tracker.firebirdsql.org/secure/IssueNavigator.jspa?sorter/field=updated&sorter/order=DESC - стопудово далеко не всё видно. Там есть что-то типа "ленты событий", чтобы в date desc видеть ВСЕ тикеты ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 00:46:05 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
тьфу, две одинаковые ссылки запостил... в общем: искал по assignee, сначала по dimitr'у, затем по alex'у. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 00:47:17 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
ТаблоидТам есть что-то типа "ленты событий", чтобы в date desc видеть ВСЕ тикеты ? Отсортировать по номеру тикета?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 00:48:57 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Сортировка по номеру тикета от сортировке по дате ничем не отличается (не должна, по крайней мере). Ты лучше не умничай, ты пальцем покажи (с) - на этой неделе таких (созданных) тикетов нет не только от ДЕ, но и вообще. Есть один тикет от ДЕ про дисконнект, а не коннект. P.S. Лента есть (browse project), поиск тоже всё показывает (хоть и не всегда удобен). И "занёс" - это не assignee, а "reporter". Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 00:55:10 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
ГРP.S. Лента есть (browse project), поиск тоже всё показываетда, я уже врубился: там фильтр был по 'unresolved', не сразу увидел. DSдва тикета, связанных с конектомПро коннект на минувшей неделе только core-4265, но он по мотивам вот этого мультфильма. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 09:16:59 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Таблоид, сказать тебе, что происходит между двумя синими строчками на клиенте ? Сюрприз - собственно удаленный коннект к базе. Итого имеем рекурсию - коннект медленный, потому что коннект медленный. Если уж хочешь искать причину - смотри консольный вывод сервера в эти промежутки времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 10:24:17 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Вот "блок" сообщений, который вываливается в консоли сервера в ответ на isql ... -user calibrator, когда НЕТ других isql'ей: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Но калибратор работает не один, там в параллели еще 450 молотилок. И вот мешанина, которая вылезает на консоли сервера в итоге: Код: 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. Как тут понять, "от кого - чего - к чему" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 11:00:55 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Таблоид, практически никак. Ибо не за тот инструмент ты взялся. Тебе (как и любому пользователю ФБ) вообще недоступны средства диагностики таких проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 11:19:22 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Ну, кое что дополнительно всё равно нарылось. Все отображаемые клиентом сообщения зашиты в src/remote/client/interface.cpp. Я добавил в него еще немного диагностического вывода (см аттач; сообщения-"добавки" имеют префикс 'nfo:' вместо 'cli:'). И получил следующий расклад для коннекта длительностью в 4 сек: Код: 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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 12:00:40 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Таблоид, не то смотришь. В выделенной тобой строчке клиент делает пересылку пакетов серверу. Собственно основная задержка либо во время самой этой пересылки (но у тебя вроде localhost), либо на сервере по обработке пересылаемого пакета, что тебе и так уже сказал dimitr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 13:29:09 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Симонов Денисосновная задержка либо во время самой этой пересылки (но у тебя вроде localhost), либо на сервере по обработке пересылаемого пакета, что тебе и так уже сказал dimitrКалибратор всегда трудится на том же хосте, что и ФБ. Чтобы исключить влияние перекрученных проводов, глюкавых хабов и прочего. В базу лезет по tcp, оттого и localhost. Я уже натолкал в функцию receive_packet_noqueue() дебаговых сообщений, с выводом номеров строк (__LINE__). Запустил всё по-новой, те же 450 молотилок с калибратором - пущай полетают. Пока что ТОП-10 тупых коннектов - так, мелкие рыбёшки: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Ну так и времени прошло всего 1 час, подождать надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 13:41:38 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Симонов Денислибо на сервере по обработке пересылаемого пакетаЕсли этот вариант, то дальше я копать не буду, тут только Монстры Рока смогут. Но я таки подожду, пущай помолотит часов 5-6, после чего посмотрим на лог сообщений, которые генерились внутри receive_packet_noqueue(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 13:45:47 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Таблоид, я в своих тестах долгие коннекты искал (и находил) именно внутри ядра ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 14:12:14 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
... посмотрел я снова в винегрет, который на серверой консоли: тихий ужос. Вот есть несколько тупых коннектов, были зарегистрированы сегодня утром (тест молотил к тому времени примерно 16 часов): Код: plaintext 1. 2. 3. 4. Беру фрагмент лога вывода на сервере для первого варианта, 08:39:53. И вижу в нём смежные сообщения с интервалом в 11 ( одиннадцать ) секунд вместо восьми: Код: 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. Для второго, в 04:07:58 - опять вижу соседние сообщения с интервалом в 11 секунд: Код: 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. И для третьего случая, - то же самое, 11 секунд: Код: 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. Выделенные строки, ясен пень, относятся к активности РАЗНЫХ isql'ей. И одиннадцать секунд сложились из ~восьми (которые "расшифрованы" калибратором) и ~трёх (которые потрачены непонятно на что). Во всех случаях (не только в показанных ТОП-10) действия от калибратора на сервере завершаются вот этой строкой: Код: plaintext Код: plaintext или Код: plaintext 1. Чё-то тут "не того"! Почему сообщения разные для SYSDBA, хотя ошибок в логах молотилок - НОЛЬ ? ЗЫ. Начало сообщений в логе сервера для коннектов от SYSDBA, кстати, тоже разное бывает: Код: plaintext 1. 2. 3. 4. 5. 6. vs Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Хрен его поймёт, в общем... :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 14:33:14 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Кольцо поисков постепенно сжимается. Для коннекта, который тупил в течение 6062 мс, в консоли клиента получены следующие метки времени по операциям внутри функции receive_packet_noqueue(): Код: 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. Первый "проблемный лаг", в 4 секунды (17:10:13. . .17:10:17), соотв-вует вот этому коду: Код: plaintext 1. 2. 3. 4. 5. В аттаче - "пронумерованная" по строкам функция receive_packet_noqueue(). Посмотрим-ка теперь на receive_packet_with_callback() поближе... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 17:43:38 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
ТаблоидВот "блок" сообщений, который вываливается в консоли сервера в ответ на isql ... -user calibrator, когда НЕТ других isql'ей: ................. ................. ................. Как тут понять, "от кого - чего - к чему" ? Нужно какой-нибудь идентификатор коннекта туда вывести (хоть автоинкрементальный), и станет уже разбираемо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 19:05:08 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
NickDeeНужно какой-нибудь идентификатор коннекта туда вывести (хоть автоинкрементальный), и станет уже разбираемо.они (srv: & cli:) когда руки трясут друг другу, то ИД коннекта нету еще. Что действительно было бы гут, это если бы клиент первым же пакетом отсылал на сервер что-то типа UUID, и дальше чтобы все сообщения процесса рукопожатия снабжались этим префиксом, а не просто 'srv:'. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 19:07:40 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Верёвка вьётся долго, "преступник" заметает следы. Я тут нарыл кое-что, но дальше нужна помощь Источников Света (наверное). Сейчас калибратор зафиксирован несколько коннектов тупизной примерно в 7 сек. Я взял наугад один, который устанавливался 6798 ms. И вижу в логе калибратора: Код: 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. Код: 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. Остаётся одно: это вызов port->receive(packet) , который в строке 6607 . Что это за функция и в где её код - я тут "русский не понимать". Указатель rem_port* port приходит через параметры из хрен знает откуда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 22:36:01 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Тебе же говорили, что проблема не в клиенте. receive ждёт ответа от сервера, и клиент на это никак повлиять не может ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 22:43:44 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
hvlad, вот что вижу в консоли сервера за период 20:16:13. . .20:16:24 Код: 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. Строки в диапазонах, отмеченных маркерами "1+". . ."1-" - это ответ сервера на запрос калибратора. Он всегда заканчивается фразой "Srv: ServerAuth(): miss data with tag 84", я уже наизусть этот текст знаю :-) Следующее упоминание калибратора видим только в 20:16:30, то есть слишком "далеко" от 20:16:13, и по первой же строке ("Srv: accept_connection: protoaccept a=1 (v>=13)=1 32781 32781") видим, что это уже деяния от ДРУГОЙ итерации bash-скрипта, т.е. от следующего вызова isql. Это значит, что строки между "1+". . ."1-" - это ПОЛНЫЙ перечень действий сервера в ответ на просьбу установить коннект. Строки в диапазонах "2+". . ."2-" и "3+". . ."3-"Строки в диапазонах "2+". . ."2-" и "3+". . ."3-" - это сервер занимается уже коннектами молотилок, они идут все из-под SYSDBA. Эти строки ("от sysdba") бывают двух видов, оттого и два цвета. Чем они отличаются визуально - хорошо видно по тексту и числу строк. А чем они отличаются на самом деле - не понятно, ну да и фиг с ними. А теперь взгляни еще раз на дырку в 6 секунд, показанную двумя постами выше , под спойлером. Как так получается: клиент ждал "чего-то там" шесть сек, с 20:16:13 по 20:16:19, а судя по сообщениям на консоли сервера, "забота" об этом клиенте пропала уже в 20:16:13 (см метку "1-") ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 23:05:31 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
Вот еще пример, коннект почти в 9 сек. Лог на консоли сервера: Код: 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. Все сообщения, относящиеся к проблемному случаю установки коннекта калибратором, на консоли сервера начинаются и заканчиваются в течение одной секунды, 23:01:44. Тогда как лог клиента гораздо более информативен: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2013, 23:21:30 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
dimitrя в своих тестах долгие коннекты искал (и находил) именно внутри ядра Тогда долгий коннект должен был бы возникать и для любой другой базы на этом хосте, если в этот момент времени идёт молотьба с "основной" тестовой базейкой. Но это не так. Я сейчас проверил по нескольку раз скорость отклика при handshaking'e в isql - как для нагружаемой (уже более 12 часов) idx_test, так и на другой базе, к которой вообще нет коннектов. ИТОГО: затыки есть при коннекте только к той базе, которая сейчас нагружена молотилками. Лог сообщений в isql для не нагруженной базы: всё укладывается менее чем в 1 сек Код: 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. Аналогичный лог для базы, которую долбят 450 молотилок вкупе с калибратором: 4 сек на port->receive(packet) Код: 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. ЗЫ. Затык в несколько секунд - не обязательно единственный, как в вышеприведенных фрагментах. Первый вызов port->receive() может заклинивать на и 5..6 сек, а последующие тоже могут "подклинивать": 6 сек + 3 сек Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2013, 06:31:06 |
|
||
|
И снова о скорости установки коннектов к Firebird при средней и сильной нагрузке
|
|||
|---|---|---|---|
|
#18+
ПолуОФФ. Интересное кино получается, когда isql показывает статистику: чересполосица какая-то :-) isql output Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. receive_packet_noqueue с натыканным debug-выводом, 122 строки Код: 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. Ну при вводе quit тоже откровение вылезло: оказывается, там будет аж четыре вызова receive_packet_with_callback(): isql output Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. receive_packet_with_callback с натыканным debug-выводом, 66 строк Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2013, 07:24:16 |
|
||
|
|

start [/forum/topic.php?fid=40&fpage=109&tid=1564133]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
48ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
73ms |
get tp. blocked users: |
1ms |
| others: | 223ms |
| total: | 395ms |

| 0 / 0 |
