|
Очень долгий Delete
|
|||
---|---|---|---|
#18+
Всем привет. Имеется таблица с свыше 600 млн строчек, удаляю около 200 млн через DELETE FROM table WHERE id IN (SELECT lala). Выборка SELECT занимает где-то до 10 мин. Все остальное - по идее должен быть DELETE. В итоге уже сутки выполняется запрос и почему-то не нагружает систему. Запрос потребляет 5-15% ЦП и диска до 15 МБ/с. Хотя скорость диска свыше 1 ГБ/с (LUN выделен). Кто может подсказать - почему так? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2020, 06:39 |
|
Очень долгий Delete
|
|||
---|---|---|---|
#18+
_WeSTMan_, Что в pg_stat_activity для этого процесса? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2020, 10:48 |
|
Очень долгий Delete
|
|||
---|---|---|---|
#18+
Павел Лузанов, Не вижу ничего особенного, state = active backend_xid = 198995119 backend_xmin = 198995119 query = "DELETE FROM act_hi_detail WHERE id_ IN (SELECT act_hi_detail.id_ FROM act_hi_detail INNER JOIN temp_bids ON act_hi_detail.proc_inst_id_ = temp_bids.processinstanceid);" id_ = первичный ключ processinstanceid - индекс есть proc_inst_id_ - индекс есть Связей с другими таблицами нет. Вижу, что запрос построен немного некорректно, может попробовать запустить так: DELETE FROM act_hi_detail WHERE proc_inst_id_ IN (SELECT processinstanceid FROM temp_bids) ?? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2020, 12:24 |
|
Очень долгий Delete
|
|||
---|---|---|---|
#18+
_WeSTMan_, 1) 5-15% процессора от 1го ядра или от всего сервера... в общем 100% оно в 1 ядра берет или нет по top 2)"скорость диска свыше 1 ГБ/с (LUN выделен)" - не важно сколько скорость на линейном чтении важно сколько IOPS дисковая выдает в секунду на случайных операциях и с какой latency (не менее важно чем iops) что показывает iostat -xmd 10 4-5 отсчетов? 3)сделайте explain (analyze, costs, buffers, timing) delete вашего с лимитом ну скажем в 100 строк и посмотрите на что уходит время (если понятнее не станет то в 10000 строк) так же сделайте explain (без analyze) вашего полного delete 4)большие операции лучше бить на батчи разумного размера которые выполняются не более минуты (и точно не более часа) 5)у вас на эту таблицу на 600м строк ниоткуда foreign keys не ведут случайно? в общем вариантов я могу придумать много (я отстортировал по снижению вероятности с моей точки зрения) 1)дисковая на случайном чтении тормозит (200m удалений легко может дать миллиард-другой случайных чтений с диска операций) 2)дисковая тормозит на записи wal большого объема 3)есть непроиндексированные fk на таблицу из которой удаляют 4)есть before/after delete триггера тормозные там же 5)какая то блокировка (кто то держит в открытой транзакции строку которую пытаются удалить) 6)кривой план запроса почему то база построила -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2020, 12:32 |
|
|
start [/forum/topic.php?fid=53&fpage=23&tid=1994508]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
2ms |
others: | 287ms |
total: | 402ms |
0 / 0 |