Idle postgres процессы занимают много памяти

Question

Я пытаюсь понять, почему ~ 30 простаивающих процессов postgres занимают столько памяти процесса после нормального использования. Я использую Postgres 9.3.1 и CentOS версии 6.3 (Final). Использования top, я могу видеть, что многие из соединений Postgres использует до 300Мб (в среднем ~ 200mb) из без общего доступа (RES - SHR) памяти:

PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
3534 postgres 20 0 2330m 1.4g 1.1g S 0.0 20.4 1:06.99 postgres: deploy mtalcott 10.222.154.172(53495) idle 
9143 postgres 20 0 2221m 1.1g 983m S 0.0 16.9 0:14.75 postgres: deploy mtalcott 10.222.154.167(35811) idle 
6026 postgres 20 0 2341m 1.1g 864m S 0.0 16.4 0:46.56 postgres: deploy mtalcott 10.222.154.167(37110) idle 
18538 postgres 20 0 2327m 1.1g 865m S 0.0 16.1 2:06.59 postgres: deploy mtalcott 10.222.154.172(47796) idle 
1575 postgres 20 0 2358m 1.1g 858m S 0.0 15.9 1:41.76 postgres: deploy mtalcott 10.222.154.172(52560) idle 

Есть около 29 всего простаивающих соединений. Эти незанятые соединения продолжают расти в памяти до тех пор, пока машина не начнет использовать swap, а затем производительность остановится. Как и ожидалось, сброс соединения очищает память, зависящую от процесса. То же самое количество подключений на одном компьютере использует только 20% памяти (с заменой 0) при повторном подключении. К какой информации относятся эти процессы? Я ожидал бы, что длительные, бездействующие процессы postgres будут иметь одинаковое использование памяти для новых, бездействующих.

Стоит отметить: я сильно использую схемы. При каждом запросе к моему приложению я устанавливаю и восстанавливаю search_path.

Answer 1

К какой информации относятся эти процессы? Я ожидал бы, что длительные, бездействующие процессы postgres будут иметь одинаковое использование памяти для новых, бездействующих.

Есть на самом деле довольно много вещей, которые Postgres будет кэшировать в локальной памяти, когда он загрузил их:

• relcache (отношение дескрипторы) (записи системного каталога)
• catcache
• скомпилированные деревья для функций plpgsql

Для большинства случаев использования все они составляют незначительную величину. Ключевым моментом здесь было интенсивное использование схем и влияние на ретрансляцию. Эта база данных содержит ~ 500 схем, каждая с одинаковыми ~ 90 таблицами. Для Postgres, хотя схемы все одинаковы, это работает до 45 000 таблиц (500 * 90).

Каждый запрос кэшировал некоторые дескрипторы отношений таблиц в памяти (чаще всего в другой схеме, чем запрос перед ним), постепенно заполняя реляк. К сожалению, Postgres does not offer a way to limit the size of these caches, поскольку накладные расходы, вероятно, будут контрпродуктивными для большинства случаев использования.

Возможные решения:

• подключение после определенного количества запросов
• Добавьте память
• пулы соединения поставить потолок на число Postgres соединений с использованием pgpool-II или PgBouncer

Спасибо Tom Lane и Merlin Moncure за помощь в этом по телефону Postgres mailing lists.