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

Я пытаюсь понять, почему ~ 30 простаивающих процессов postgres занимают столько памяти, зависящей от процесса, после обычного использования. Я использую Postgres 9.3.1 и CentOS версии 6.3 (Final). Используя top, я вижу, что многие из подключений postgres используют до 300 МБ (в среднем ~ 200 мб) памяти без общего доступа (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.

Ответы

Ответ 1

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

На самом деле Postgres будет кешировать в локальной памяти после загрузки:

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

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

Каждый запрос кэшировал некоторые дескрипторы отношений таблиц в памяти (чаще всего в схеме, отличной от запроса перед ним), постепенно заполняя relcache. К сожалению, Postgres не предлагает способ ограничить размер этих кэшей, так как накладные расходы, вероятно, будут контрпродуктивными в большинстве случаев использования.

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

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

Спасибо Тому Лейну и Мерлину Монкьюру за помощь в списках рассылки Postgres.