name,setting,unit from pg_settings where category = 'Resource Usage / Memory';
2) значение max_connections
3) объем RAM и swap
?
1) Autovacuum_work_mem -1 Dynamic_shared_memory_type posix Huge_pages try Maintance_work_mem. 2097152 Max_prepared_transactions. 1655 Max_stack_depth 2048 Plan_cache_lru_memsize 8192 Plan_cache_mem_size. 0 Shared_buffers. 2621440 Shared__memory_type Mmap Temp_buffers. 1024 Track_activity_query_size. 1024 Work_mem 102400 2) 1000, но реально больше 240 не бывает 3) 85gb mem, 4gb swap
покажите еще sysctl vm.overcommit_memory vm.overcommit_ratio
Вот их не было задано по рекомендации, спасибо за информацию, буду мониторить.
ну и вообще желательно иметь под рукой график использования памяти и какое-то подобие трекинга выполняемых запросов (из pg_stat_activity), чтобы видеть когда началось уменьшение доступной памяти и какие запросы выполнялись в тот момент - тогда будет больше информации для дебага.
И да, а huge pages на самом деле используются (потому что если нет, то стоило бы)? И какая полная версия PostgreSQL? Потому что вот это: Plan_cache_lru_memsize 8192 Plan_cache_mem_size. 0 Это что-то "левое", например.
Это Postgres pro Huge pages не используются, но в планах
Запросов идёт очень большое количество, график потребления памяти есть, но рост идёт постепенный и как вычислить виновника не очень понимаю.
поднимите логи, обычно в момент завершения процесса, фиксируется запрос который там выполнялся, например 2021-06-04 12:44:30.613 +05 1205 @ from [vxid: txid:0] [] LOG: server process (PID 1280709) was terminated by signal 9: Killed 2021-06-04 12:44:30.613 +05 1205 @ from [vxid: txid:0] [] DETAIL: Failed process was running: select pg_sleep(300); 2021-06-04 12:44:30.613 +05 1205 @ from [vxid: txid:0] [] LOG: terminating any other active server processes тут интересно, это всегда один и тот же тип запроса, или разные? Если один и тот же надо взяться за его изучение, погонять с EXPLAIN и разными параметрами, посмотреть на планы, вобщем присмотреться. Если разные то дальше думать над вариантами.
Пока выцепить запрос не успел, но нашёл другую вероятней всего интересную вещь: Из 220 коннектов в среднем, только 30 в среднем активны, остальные процентов 60 idle и 25 idle in transaction. Это может быть причиной высокого потребления памяти?
Вы до сих пор не https://t.me/pgsql/308393 ? ;) Я о том, что так можно очень долго гадать...
Гасить их с помощью тайм-аута?
Нет. Получить нормальные ошибки out of memory в тех процессах, где это действительно происходит (и в логах, соответственно), вместо OOM kills левых процессов.
Обсуждают сегодня