|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
При выполнении сложных запросов, массовых заливок Postgres жутко тормозит. Почитал рекомендации пошаманил в postgresql.conf (прилагаю). Ничего не дает - по прежнему загрузка ЦП 100%, загрузка памяти 3% Куды копать? Может вовсе не postgres виноват, а Линукс? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 12:05 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
an2kПри выполнении <>, массовых заливок Postgres жутко тормозит. предположим СУБД вместо того чтобы залить данные на диск (поюзать дисковую) поюзало память. и туточки всё упало (где-то там перемкнуло в БП или обоих, или даже на мамке бумкнуло) -- и оно так в памяти и сдохло, не попав на диск -- оно вам надо ? ну и про запросы: -- какие запросы ? тексты, планы, вот это всё -- где оно ? то, что 100 % проца -- может означать, что запросы вычислительно дорогие, например, а память им нахер не упала. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 13:10 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
Вот функция Код: plsql 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.
Вот ее вызов: Код: sql 1.
на таблице размером 20 млн. записей зависает на сутки. План посоветуйте как посмотреть, плз. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 13:33 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
an2k, осторожно поинтересуюсь: 1 скока дистинктных lw_table_name вы ожЫдаете наблюсть в вашей log_write ? и 2. есть ли индекс на log_write, начинающийся с lw_table_name , (но, упаси, не богомерзкий текст/варчар_паттерн_опс, а нормально поддерживающий поиск правых/левых ветвей ) фак ультативнои да, похоже вашу задачу писали дятелы на оть@бись, а не для того, чтобы она таки нормально решалась (я бы, наверное, делал её короткими частями, скорее всего, и , возможно, даже в параллель по диапазонам lw_table_name, с небольшой опорной табличкой лога отработанных ключей ) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 14:13 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
an2kПлан посоветуйте как посмотреть, плз. Код: sql 1.
но это неинтересно интересно что--нть типа Код: sql 1. 2. 3. 4. 5. 6. 7.
ну и т.п. хотя и оно не интересно, ибо, имхо, нехрен реализовывать ваш скрипт как он есть вообще. пс. а конкурирующие читатели писатели у вас имеются ? эдак вы ещё можете всё время в очередь вставать за оными. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 14:22 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
qwwq, 1. Около 30 2. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 18:43 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
qwwq, 3. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
4. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Не могли бы прокомментировать этот результат? PS: Конкурирующих читателей/писателей нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 18:50 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
an2k, вы всё ещё настаиваете на удалении 20лямов (хотя в плане у вас всего 5.5лямов) записей 1--й транзакцией ? если да -- то это 1. делается одним запросом.(напишите этот запрос [используйте кляузу USING для набора оставляемых записей] и посмотрите на его план) //и еще думаю, не помог бы вам тут, часом, индекс (lw_table_name,lw_rec_id,id). не совсем ясно, что у вас с плотностью lw_rec_id -- для получения max(id) по группам и самих групп для using 2. или за один проход for loop по сортированному набору. (факультативно, тут скорее всего это не интересно) Код: plaintext
немного оффтопапо вашей процедуре: есть ли у вас таблица "имен таблиц" ? если да, зачем вы упираетесь с дистинктом ? (он конечно сутки не занимает, но все ж таки лишняя работа). или ознакомьтесь с loose-indexcan--ом. тоже вариант. в вашем случае он (дистинкт) вообще может быть for loop-ом по одной записи, следующей вдоль индекса lw_table_name. (SELECT lw_table_name INTO _lw_table_name FROM mytable WHERE lw_table_name >_lw_table_name ORDER BY lw_table_name LIMIT 1). и да: не налегайте на динамический sql там, где планируете 10-ки тысяч синтаксических разборов. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 19:44 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
an2k, так не пробовали? Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 19:49 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
Павел Лузанов, вот,да. можно и без using. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 19:55 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
an2k, А сколько в штуках строк остается? Может, сделать наоборот: 1. Выбрать остающиеся строки во временную таблицу 2. Очистить имеющуюся таблицу (truncate) 3. Вставить остающиеся записи в таблицу из временной. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 22:04 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
ursido, это работает если нет конкурентных обращений к табличке. можно это же сделать без времянок: -- создаем 2 ротируемые партиечки. можно с триггером before insert [с перегружаемым тестом ф-ии] подстановки номера рабочей партиции на пустом предке, но обычно дешевле с подстановкой имен на уровне хранимок вставки, если обработка в основном массовая ) обеспечиваем лок записи о рабочей партиции на момент ротации. (т.е. очередь, и строгую одномоментность). и переключаем партиции. после переключения рабочей партиции делаем сдвиг оставляемых записей что-то типа: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
-- в любой момент табличка--предок доступна для чтения (с точностью до лока потомка на момент транкейта [тут можно выводить потомка из иерархии, что м.б. быстрее транкейта. но это чревато ошибкой в уже спланированных и выполняющихся запросах] ) накладные -- куча хенджоба. и усложнение планов запросов к таблице выигрыш -- снятие проблем вакуумирования и перестройки индексов при массовой очистке ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 22:47 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
qwwq, То что Вы описали сильно напоминает механизм ротации очередей Londiste. Имеет смысл посмотреть их реализацию. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.05.2017, 23:09 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
All, Прошу прощения, я не сказал в чем смысл: В базе несколько таблиц: Студенты Преподаватели Оценки Они в течении времени могут меняться (исправление опечатки в ФИО, изменение оценки, etc.) Все эти изменения (включая первичный insert) фиксировались в таблице log_write для того, чтобы другие системы могли периодически получать из этой базы только изменившиеся (или новые) данные. Для того чтобы системы-потребители знали, что они уже получили и не читали повторно, есть еще таблица log_read, в которой фиксируются сеансы чтения, но это к нашему вопросу не относится. До сих пор в log_write хранились все изменения, теперь решено оставить только последние, а все неактуальные удалить. Всего их было 20 млн. остаться должно 5-6. Т.е. необходимо удалить из таблицы log_write все записи, оставив по одной для каждого уникального значения поля lw_table_name, притом с наибольшим для этого значения id. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 07:19 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
Павел Лузанов, Попробовал. После трех часов работы остановил. Более быстрого способа не придумать? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 10:13 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
ursido, хорошая идея, но сломал голову, как выбрать только строки с максимальным id или не выспался или голову на свалку (( ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 10:17 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
an2k, Мне кажется, Вам нужно остановиться и собраться с мыслями. Эта задача написана в темах выше уже несколько раз. Как соберетесь с мыслями, смотрите (скопировано из поста выше 20528831 ): Код: sql 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 10:25 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
an2kПавел Лузанов, Попробовал. После трех часов работы остановил. Более быстрого способа не придумать? покажите Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
для какого-нить существующего 'any_lw_table_name', но не самого частого. чтобы уложжиться. и следите за состоянием соединения через pg_stat_activity. т.к. в задаче, как она поставлена, все время присутствуют конкурирующие обращения. (в логируемые таблы кто--то пишет и переписывает) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 10:38 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
qwwq, По постановке задачи от таблицы должно остаться примерно 25% записей. Вариант с удалением вызывает тоску. Предлагаю следующее действие: Выбираем строки, которые нужно оставить. Среди них фиксируем самую раннюю дату. Теперь все строки в таблице, более ранние чем зафиксированная дата, можно удалять по дате. После этого можно вернуться к задаче с меньшим количеством строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 10:52 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
ursido, не спешите. я хочу увидеть план. а в нем отсутствие триггеров. удалить 20 лямов узких рекордов -- это как кот чихнул. если ничто не мешает. в последнем я сильно сомневаюсь. а дальше копируем , на коленке, ротацию с pgq, если помехи есть ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:03 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
ursido, как вариант -- удалять запись--писи в исходной хранимке ТС (вернее её аналога с прямым проходом по сортированному набору) можно автономно через дблинк. это сильно развязывает руки. плюс нарезать головной процесс на слайсы минут по 10--20, посредство statement_timeout для выделенного ползателя. во избежание излишне долгой транзакции. и не надо никаких ротаций. но перестраивать индексы пж-у придётся долго и упорно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:11 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
qwwq, Я не смогу его потом развидеть. В предложенном Вами запросе имеются: -- Группировка по полям без индекса с составными полями (нет индекса, под эту группировку) -- Предложение NOT IN (SELECT ...) Причем эти действия равномерно размазаны между отдельными группами (этих групп со слов автора примерно 5-6 млн). Какие еще более медленные запросы Вы знаете? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:12 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
qwwq, И еще напомню, что прямо сейчас автовакуум отключен. (Надеюсь, только на период интенсивной обработки данных). ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:13 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
ursidoqwwq, Я не смогу его потом развидеть. В предложенном Вами запросе имеются: -- Группировка по полям без индекса с составными полями (нет индекса, под эту группировку) -- Предложение NOT IN (SELECT ...) Причем эти действия равномерно размазаны между отдельными группами (этих групп со слов автора примерно 5-6 млн). Какие еще более медленные запросы Вы знаете? вам же ТС отписался, что это займет примерно Execution time: 8767.513 ms если так боитеся что NOT IN (SELECT ...) распишите его через Код: sql 1. 2. 3. 4. 5.
это механическая работа или даже через что--то навроде: Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
это ТОЖЕ механическая работа вы, как минимум, навяжете однократную материализацию (хотя она и так там д.б. однократной) думаю проблема не в том , чтобы просканировать и сгруппировать всю табличку [Execution time: 8767.513 ms ], а в том, что где--то что--то во что--то упирается. варианты -- триггера (в т.ч. констрайнтовые) или локи конкурентов. пока не узнаем -- дальше не ясно. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:29 |
|
Postgres не хочет юзать память
|
|||
---|---|---|---|
#18+
Да. Ждем ответа от автора. Пока продолжим: qwwq... вам же ТС отписался, что это займет примерно Execution time: 8767.513 ms ... И это время (8 секунд) будет затрачено на подзапрос для каждой из строк, которых 20 млн. По-моему тормозилово именно здесь (то есть во вложенном подзапросе) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:37 |
|
|
start [/forum/topic.php?fid=53&msg=39463654&tid=1996476]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 330ms |
total: | 458ms |
0 / 0 |