powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
16 сообщений из 16, страница 1 из 1
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540468
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hi all

В некоторой таблице (1136988 строк) есть 4 числовых поля f07, f08, f09 & f10; заполнены всякой рандом-белибердой.
В окне-1 выполняю запрос:
Код: plaintext
set stat on;  select count(*) from tmp a join tmp b on abs(a.f07+a.f09)=abs(b.f08+b.f10);
(вернёт значение около 1 млн).

В окне-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.
set autoddl off;
set list off;
set blob on;
set width dts 12;
set width mon_user 20;
set width remote_process 30;
set width sql_txt 50;
set width remote_ip 15;
set width rn 3;
set heading off;
select substring(cast(current_timestamp as varchar(25)) from 12 for 12) dts,'iter #'||1 msg from rdb$database;
set heading on;
commit;
select
     substring(cast(current_timestamp as varchar(25)) from 12 for 12) dts
     -- mon$attachments:
     ,cast(row_number()over(order by mon$attachment_id) as char(3)) rn
     ,a.mon$remote_address remote_IP
     ,a.mon$attachment_id attach_id
     ,a.mon$user mon_user
     ,a.mon$stat_id       stat_id
     ,a.mon$server_pid    server_PID
     ,a.mon$remote_pid    remote_PID
     -- mon$memory_usage:
     ,u.mon$memory_used used_memory
     ,u.mon$memory_allocated alloc_by_OS
     -- mon$io_stats:
     ,i.mon$page_reads reads
     ,i.mon$page_writes writes
     ,i.mon$page_fetches fetches
     ,i.mon$page_marks marks
     -- mon$record_stats:
     ,r.mon$record_seq_reads seq_reads
     ,r.mon$record_idx_reads idx_reads
     ,r.mon$record_inserts ins_cnt
     ,r.mon$record_updates upd_cnt
     ,r.mon$record_deletes del_cnt
     ,r.mon$record_backouts bk_outs
     ,r.mon$record_purges purges
     ,r.mon$record_expunges expunges
     -- aux info:
     ,right(a.mon$remote_process,30) remote_process
     -- mon$statements:
     --,left(cast(s.mon$sql_text as varchar(32760)),50) sql_txt
from mon$attachments a
      left join mon$memory_usage u on a.mon$stat_id=u.mon$stat_id
      left join mon$io_stats i on a.mon$stat_id=i.mon$stat_id
      left join mon$record_stats r on a.mon$stat_id=r.mon$stat_id
where
      a.mon$attachment_id<>current_connection
;
 shell sleep 1; 

set heading off;
select substring(cast(current_timestamp as varchar(25)) from 12 for 12) dts,'iter #'||2 msg from rdb$database;
 commit; 
select
     substring(cast(current_timestamp as varchar(25)) from 12 for 12) dts
     -- mon$attachments:
     ,cast(row_number()over(order by mon$attachment_id) as char(3)) rn
     ,a.mon$remote_address remote_IP
     ,a.mon$attachment_id attach_id
     ,a.mon$user mon_user
. . .
where
      a.mon$attachment_id<>current_connection
;
shell sleep 1;

. . . etc еще 7200 раз. . .


ФБ работает в режиме SuperClassic, изменённые настройки конфига:
Код: plaintext
1.
2.
3.
4.
5.
6.
$ grep "^[^#;]" firebird.conf | sort
FileSystemCacheThreshold = 1024K
SharedCache = false
SharedDatabase = true
TempBlockSize = 100M
TempCacheLimit = 1024M
TempDirectories = /dev/shm

Кеш коннекта в первых двух прогонах был умалчиваемый (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().

Чем объяснить "падёж скота" на первых же секундах ?
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540488
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в самом начале целиком читается, хешируется и буферизируется одна из сторон джойна, при этом ничего больше не делается. Потом эта таблица уже никогда не читается постранично, поэтому фетчей из нее нет. Вторая сторона будет читаться и для нее фетчи будут, но тут уже подключается перебор коллизий в хеш-таблице, вычисление abs и проверка условия, построчная выдача результата вверх по стеку (count(*) это быстро обрубает, но тем не менее). Все это жрет процессор больше чем чтение таблицы из кеша, поэтому число фетчей в единицу времени падает.
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540500
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

сначала идёт построение хэш таблицы, поэтому число чтений большое. Далее двигаемся натуралом по другой таблицы и вычисляем хэш по ней и сравниваем его с ключами в хэш таблице. Обращение в хэш таблицу в фетчах вроде как не учитываются. А если там количество коллизий большое, то это обращение может быть неоднократным.
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540505
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrподключается перебор коллизий в хеш-таблице, вычисление abs и проверка условия, построчная выдача результата вверх по стеку (count(*) это быстро обрубает, но тем не менее). Все это жрет процессор больше чем чтение таблицы из кеша, поэтому число фетчей в единицу времени падает.Есть смутное сомнение, что именно коллизии в ХТ, а не вычисление abs и тем паче проверка на равенство, - это и есть главная причина.
Можно ли как-то регулировать число слотов этой хеш-таблицы ?
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540508
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

нельзя. Пока (для отладки) число слотов фиксировано и невелико, отсюда тормоза на больших таблицах. Как только оптимизатор научится оценивать размер входящего потока, тогда подходящее число слотов будет выбираться оптимизатором.
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540514
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrКак только оптимизатор научится оценивать размер входящего потока, тогда подходящее число слотов будет выбираться оптимизатором.а если один или оба источника в джойне будут хранимые процедуры, размер выборки из которых оценить вообще нельзя, - тогда что ?
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540520
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

объединит merge
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540531
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

либо будет использована некая оценочная константа в качестве кардинальности ХП. Сейчас так оно и есть для nested loops, правда оно по ряду причин мало на что влияет.
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540564
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrПока (для отладки) число слотов фиксировано и невелико, отсюда тормоза на
больших таблицах.
Если сделать список коллизий сортированным, тормозов станет вдвое меньше.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540597
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
если таблоид мне в почту накидает пяток примеров - при возможности поглядим, что там можно улучшить
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540623
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrесли таблоид мне в почту накидает пяток примеров - при возможности поглядим, что там можно улучшитьдык не вопрос, только наменки: примеры какого вида надо ? ну, то есть, ЧТО там надо показать / доказать етц ?
ЗЫ. А временно как-нибудь нельзя config-параметр ввести, регулирующий число слотов в ХТ ?..
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540628
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

в первую очередь интересны примеры, которые в 2.5 при плане merge join выполняются на порядок быстрее, чем в 3.0 при плане hash join. Во-вторую - любые запросы, выполняющиеся в 3.0 при hash join на порядок медленнее, чем при nested loop join. Все это с числом записей не более миллиона.
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540629
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЗЫ. А временно как-нибудь нельзя config-параметр ввести, регулирующий число слотов в ХТ ?..
нельзя
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540644
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrлюбые запросы, выполняющиеся в 3.0 при hash join на порядок медленнее, чем при nested loop joinс merge vs hash - попробую, вроде было что-то.
А вот чтобы HJ выполнялся в 10 раз тупее, чем NL - это трудновато такое представить, пока не встречал :-)
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38540663
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

чем больше входные таблицы, тем сильнее (при текущих вводных) HJ может отставать от NLJ, тем более если NLJ идет по PK. Ну и цепочки из трех-четырех-пяти джойнов любопытно проверить.
...
Рейтинг: 0 / 0
мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
    #38541202
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrчем больше входные таблицы, тем сильнее (при текущих вводных) HJ может отставать от NLJ, тем более если NLJ идет по PK. Ну и цепочки из трех-четырех-пяти джойнов любопытно проверить.отправил в личку.
...
Рейтинг: 0 / 0
16 сообщений из 16, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / мониторинг запроса с hash join: число фетчей в 1 сек резко падает через 3-4 сек. Why ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]