|
|
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
hi all В некоторой таблице (1136988 строк) есть 4 числовых поля f07, f08, f09 & f10; заполнены всякой рандом-белибердой. В окне-1 выполняю запрос: Код: plaintext В окне-2 стартую isql с большим скриптом, опрашивающим каждую 1 секунду mon$-таблицы: Код: 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. ФБ работает в режиме SuperClassic, изменённые настройки конфига: Код: plaintext 1. 2. 3. 4. 5. 6. Кеш коннекта в первых двух прогонах был умалчиваемый (256), сделал два запуска. Затем задрал его до 524288 страниц, сделал 1 запуск. По окончании запроса (он длится около 10 минут) лезу в лог мон-скрипта, причёсываю его и добавляю столбцы с вычислением разностей по fetches, reads & seq_reads. И вижу, что в самом начале, чуть ли не за 1 сек, идёт "вычитка" почти всей таблицы - очевидно, для построения хеш-таблицы. Но затем всё падает до плинтуса и так и остается до конца запроса: DTSUSED_MEMORYALLOC_BY_OSREADSDIFF_READSFETCHESDIFF_FETCHESSEQ_READSDEFF_SEQ12:44:18.877220716837478407964111412:44:19.882218027236167687906410114012:44:20.888317497363962858421478213991624989162434879079279067812:44:21.90648391144603461523087393952338276713287113804634725412:44:22.91148391144603461523091845234173434581139730168412:44:23.916483911446034615230962442345224349011414311701 Отличие для кеша = 256 vs 524288 вижу только в динамике reads: при кеше в 512к они сразу стали нулевыми, но это и так понятно. Однако, число фетчей в секунду резко падает при любом кеше, на 2..3-ей секунде после старта (см аттач). Свопом на диск этого не объяснить: TempCacheLimit задан чумового размера, в 5 раз больше базы, да и мониторинг юзания времянок показывает пустоту. База была "разогрета" предварительным select count(). Чем объяснить "падёж скота" на первых же секундах ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 13:52:04 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
в самом начале целиком читается, хешируется и буферизируется одна из сторон джойна, при этом ничего больше не делается. Потом эта таблица уже никогда не читается постранично, поэтому фетчей из нее нет. Вторая сторона будет читаться и для нее фетчи будут, но тут уже подключается перебор коллизий в хеш-таблице, вычисление abs и проверка условия, построчная выдача результата вверх по стеку (count(*) это быстро обрубает, но тем не менее). Все это жрет процессор больше чем чтение таблицы из кеша, поэтому число фетчей в единицу времени падает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 14:02:56 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, сначала идёт построение хэш таблицы, поэтому число чтений большое. Далее двигаемся натуралом по другой таблицы и вычисляем хэш по ней и сравниваем его с ключами в хэш таблице. Обращение в хэш таблицу в фетчах вроде как не учитываются. А если там количество коллизий большое, то это обращение может быть неоднократным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 14:05:48 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
dimitrподключается перебор коллизий в хеш-таблице, вычисление abs и проверка условия, построчная выдача результата вверх по стеку (count(*) это быстро обрубает, но тем не менее). Все это жрет процессор больше чем чтение таблицы из кеша, поэтому число фетчей в единицу времени падает.Есть смутное сомнение, что именно коллизии в ХТ, а не вычисление abs и тем паче проверка на равенство, - это и есть главная причина. Можно ли как-то регулировать число слотов этой хеш-таблицы ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 14:07:50 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, нельзя. Пока (для отладки) число слотов фиксировано и невелико, отсюда тормоза на больших таблицах. Как только оптимизатор научится оценивать размер входящего потока, тогда подходящее число слотов будет выбираться оптимизатором. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 14:10:00 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
dimitrКак только оптимизатор научится оценивать размер входящего потока, тогда подходящее число слотов будет выбираться оптимизатором.а если один или оба источника в джойне будут хранимые процедуры, размер выборки из которых оценить вообще нельзя, - тогда что ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 14:15:25 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, объединит merge ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 14:16:44 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, либо будет использована некая оценочная константа в качестве кардинальности ХП. Сейчас так оно и есть для nested loops, правда оно по ряду причин мало на что влияет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 14:23:15 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
dimitrПока (для отладки) число слотов фиксировано и невелико, отсюда тормоза на больших таблицах. Если сделать список коллизий сортированным, тормозов станет вдвое меньше. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 14:42:23 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
если таблоид мне в почту накидает пяток примеров - при возможности поглядим, что там можно улучшить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 15:03:47 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
dimitrесли таблоид мне в почту накидает пяток примеров - при возможности поглядим, что там можно улучшитьдык не вопрос, только наменки: примеры какого вида надо ? ну, то есть, ЧТО там надо показать / доказать етц ? ЗЫ. А временно как-нибудь нельзя config-параметр ввести, регулирующий число слотов в ХТ ?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 15:12:52 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, в первую очередь интересны примеры, которые в 2.5 при плане merge join выполняются на порядок быстрее, чем в 3.0 при плане hash join. Во-вторую - любые запросы, выполняющиеся в 3.0 при hash join на порядок медленнее, чем при nested loop join. Все это с числом записей не более миллиона. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 15:16:15 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
ТаблоидЗЫ. А временно как-нибудь нельзя config-параметр ввести, регулирующий число слотов в ХТ ?.. нельзя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 15:16:46 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
dimitrлюбые запросы, выполняющиеся в 3.0 при hash join на порядок медленнее, чем при nested loop joinс merge vs hash - попробую, вроде было что-то. А вот чтобы HJ выполнялся в 10 раз тупее, чем NL - это трудновато такое представить, пока не встречал :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 15:24:10 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
Таблоид, чем больше входные таблицы, тем сильнее (при текущих вводных) HJ может отставать от NLJ, тем более если NLJ идет по PK. Ну и цепочки из трех-четырех-пяти джойнов любопытно проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 15:33:41 |
|
||
|
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
|
|||
|---|---|---|---|
|
#18+
dimitrчем больше входные таблицы, тем сильнее (при текущих вводных) HJ может отставать от NLJ, тем более если NLJ идет по PK. Ну и цепочки из трех-четырех-пяти джойнов любопытно проверить.отправил в личку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2014, 20:06:49 |
|
||
|
|

start [/forum/topic.php?fid=40&fpage=104&tid=1563937]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
309ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 628ms |

| 0 / 0 |
