PostgreSQL + Apache пул соединений: MaxIdle и MaxActive против использования ОЗУ - PullRequest
1 голос
/ 28 января 2020

Мы используем базу данных PostgreSQL в облаке Google. Помимо этого у нас есть приложение. В приложении мы можем настроить параметры пула подключений во время выполнения для базы данных.

Наш сервер Google SQL имеет 30 ГБ оперативной памяти, поэтому значение max_connections по умолчанию равно 500, как я прочитал в документации Google. В нашем приложении мы установили следующие параметры пула подключений (Apache pooling):

  • MaxActive: 200
  • MaxIdle: 200
  • MinIdle: 50

У нас возникли проблемы с этими настройками. Прежде всего, мы часто сталкиваемся с лимитом MaxActive. Я могу видеть плоскую линию на графике соединений на 200 соединений пару раз в день. В эти моменты наши журналы переполнены SQL ошибками подключения.

Сервер использует около 28 ГБ оперативной памяти в пиковые моменты (с 200 активными соединениями). Таким образом, мы также близки к пределу оперативной памяти.

Вместо того, чтобы слепо увеличивать ОЗУ и MaxActive, я надеялся получить некоторое представление о том, что будет лучшим опытом в нашей ситуации. Я вижу 2 решения нашей проблемы:

  1. Увеличение оперативной памяти, увеличение MaxActive и увеличение MaxIdle (не очень экономично)
  2. Увеличение MaxActive, оставьте MaxIdle таким же (или даже ниже) и оставьте значение MinIdle таким же (или даже ниже)

Вариант 1 будет более дорогостоящим, поэтому мне интересно узнать вариант 2. Поскольку я уменьшаю число незанятых соединений, я бы занимал меньше оперативной памяти. Однако будет ли это заметно влиять на производительность? Считалось, что я держу MaxIdle как можно ближе к MaxActive, чтобы обеспечить наименьшую нагрузку при создании новых подключений.

Я провел немало исследований, но пришел к выводу, что настройка этих параметров очень специфична для конкретной ситуации c и на этих настройках не существует общих рекомендаций. Я не смог найти однозначного ответа о влиянии на производительность варианта 1 против варианта 2.

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

Я действительно надеюсь, что кто-то может дать некоторые полезные идеи / советы / лучшие практики. Заранее большое спасибо!

...