|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
Добрый день. В БД(общий размер 400 gb) с такими настройками max_connections = 1000 shared_buffers = 1GB effective_cache_size = 2GB work_mem = 50MB maintenance_work_mem = 80MB min_wal_size = 1GB max_wal_size = 2GB checkpoint_completion_target = 0.9 wal_buffers = 16MB default_statistics_target = 100 datestyle = 'iso, dmy' max_locks_per_transaction=40000 track_activities = on track_activity_query_size = 16384 autovacuum = on autovacuum_max_workers = 3 (на сервере с alt linux (16 ядер, 8gb оперативной памяти, 50 gb swap)) существуют 30 схем по 300 таблиц в каждой. Некоторые таблицы(с индексами) имеют размер 20 gb.(без учета индексов по 800mb) При формировании отчета по размерам таблиц вот таким запрсом: Код: sql 1. 2. 3. 4.
начинается использование swap вплоть до 50gb, там заканчивается место и сервер падает. Причем, оперативная память в этот момент есть свободная. Вывод free -m Код: powershell 1. 2. 3. 4.
вывод Код: powershell 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Пробовал разные настройки shared_buffers(до 4 gb) и effective_cache_size (до 6gb), но результат такой же. Примерно похожая ситуация возникает и при снятии копии БД утилитой pg_dump. Подскажите пожалуйста, можно ли понять почему так происходит и как уменьшить использование swap. Запрос с размерами таблиц приведен для примера-больше всего хочется понять почему подобное происходит вообще и как правильно нужно настраивать. Или с этим ничего не сделать и нужно для такой БД более мощный сервер использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 08:19 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
Visermoz, покажите план вашего запроса explain <ваш запрос> ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 09:58 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
Visermoz, А покажите что показывает select count(*) from pg_tables; на этой базе. Если не отработает то select count(*) from pg_class where relkind='r'; -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 10:44 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
VisermozПробовал разные настройки shared_buffers(до 4 gb) и effective_cache_size (до 6gb), но результат такой же. Примерно похожая ситуация возникает и при снятии копии БД утилитой pg_dump. Подскажите пожалуйста, можно ли понять почему так происходит и как уменьшить использование swap. Запрос с размерами таблиц приведен для примера-больше всего хочется понять почему подобное происходит вообще и как правильно нужно настраивать. Или с этим ничего не сделать и нужно для такой БД более мощный сервер использовать. Вероятнее всего ответ будет что надо больше памяти на сервере под такую базу. Кстати а что дает select count(*) from pg_class; на этой базе? Проблема в кешировании структуры всех таблиц (к которым обратились) и индексов в памяти backend, в вашем случае это приводит к кешированию структуры вообще всей базы а она судя по вашему описанию очень развесистая у вас. Проблема называется relcache bloat: Пример проблемы тут вот https://www.postgresql.org/message-id/flat/20171129100649.1473.73990@wrigleys.postgresql.org -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 11:42 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
gav21, Код: sql 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.
Согласен, лучше было бы не на вьюшку делать,а напрямую к системному словарю- тогда план получается приятнее Код: sql 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 12:05 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
Maxim Boguk, Запросы выполнились быстро Код: plsql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 12:05 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
Интересно, что запрос Код: sql 1. 2. 3. 4. 5.
выполнился за 3 секунды без всякой нагрузки на БД и swap! ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 12:09 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
gav21 , Maxim Boguk , спасибо вам за советы и помощь. С этим запросом, после переписывания с представления information_schema.tables на таблицы системного словаря всё стало работать как нужно. Вероятно, при использовании pg_dump происходит как раз relcache bloat. В базе помимо большого количества таблиц в каждой схеме существуют по ~ 3000 представлений. Этот вопрос обсуждали в http://www.sql.ru/forum/1278360/pg-dump-zanimaet-vsu-operativnuu-pamyat-i-ves-swap, но пришлось снимать не все схемы в один файл, а в несколько файлов. Там тоже было большое использование swap, но при выполнении pg_get_viewdef при сохранении структуры БД утилитой pg_dump. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 12:16 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
Visermozgav21 , Maxim Boguk , спасибо вам за советы и помощь. С этим запросом, после переписывания с представления information_schema.tables на таблицы системного словаря всё стало работать как нужно. Вероятно, при использовании pg_dump происходит как раз relcache bloat. В базе помимо большого количества таблиц в каждой схеме существуют по ~ 3000 представлений. Этот вопрос обсуждали в http://www.sql.ru/forum/1278360/pg-dump-zanimaet-vsu-operativnuu-pamyat-i-ves-swap, но пришлось снимать не все схемы в один файл, а в несколько файлов. Там тоже было большое использование swap, но при выполнении pg_get_viewdef при сохранении структуры БД утилитой pg_dump. Я даже могу обьяснить почему у вас ООМ при использовании information_schema.tables Если вы посмотрите на определение \d+ information_schema.tables Вы там увидите: WHERE (c.relkind = ANY (ARRAY['r'::"char", 'v'::"char", 'f'::"char"])) 'v'::"char" - это как раз эти самые views которые вам и дают ООМ. А при прямой работе с pg_class - вы их не цепляете и поэтому запрос работает. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 12:58 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
Maxim Boguk, да, точно. Большое спасибо за пояснение. Подскажите пожалуйста по ответу Tom Lane: "but why wouldn't it get reclaimed at the end of each tuple cycle?". К сожалению, я не понял термин "Цикл кортежей". Имеется ввиду просто выборка и то что память освободится когда получение данных завершится? Еще он пишет, что "pg_dump вытягивает описание вьюшек последовательно, одну за другой, а не целым запросом", но для самого серверного процесса ведь большой разницы нет- что так, что так relcache будет заполняться и освободится только когда процесс завершится? Поэтому для такой базы решением будет увеличение памяти(или swap) или снятие копии без представлений? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 13:23 |
|
Жуткий swap от запроса
|
|||
---|---|---|---|
#18+
VisermozMaxim Boguk, да, точно. Большое спасибо за пояснение. Подскажите пожалуйста по ответу Tom Lane: "but why wouldn't it get reclaimed at the end of each tuple cycle?". К сожалению, я не понял термин "Цикл кортежей". Имеется ввиду просто выборка и то что память освободится когда получение данных завершится? Еще он пишет, что "pg_dump вытягивает описание вьюшек последовательно, одну за другой, а не целым запросом", но для самого серверного процесса ведь большой разницы нет- что так, что так relcache будет заполняться и освободится только когда процесс завершится? Поэтому для такой базы решением будет увеличение памяти(или swap) или снятие копии без представлений? Да или без views или памяти сильно больше выдать (8Gb даже на ноуте сейчас это очень мало). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2018, 14:14 |
|
|
start [/forum/topic.php?fid=53&msg=39667058&tid=1995700]: |
0ms |
get settings: |
12ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
166ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
others: | 296ms |
total: | 565ms |
0 / 0 |