Каково идеальное количество макс. Соединений для базы данных postgres? - PullRequest
Новая
       54

Каково идеальное количество макс. Соединений для базы данных postgres?

0 голосов
/ 10 февраля 2020

В настоящее время я использую пул соединений по умолчанию в sequelize, который выглядит следующим образом: 

const defaultPoolingConfig = {
  max: 5,
  min: 0,
  idle: 10000,
  acquire: 10000,
  evict: 10000,
  handleDisconnects: true
};

В последнее время я получаю эти ошибки ResourceRequest timed out, которые связаны с вышеуказанной конфигурацией БД. Согласно некоторым ответам максимальный пул должен быть установлен на 5, но те , которые сталкивались с вышеупомянутым, Тайм-аут ресурса, ошибка предложили увеличить размер пула до 30, наряду с увеличением время приобретения.

Мне нужно знать, какое должно быть оптимальное значение максимального размера пула для веб-приложения.

Редактировать: 1.Дает, что у меня 200 одновременных пользователей и 20 одновременных запросов. , Тогда какие должны быть значения?
2. Моя база данных предоставляется GCP со следующей конфигурацией: vCPUs 1
Память 3.75 ГБ SSD-накопитель 10 ГБ

Я добавляю несколько графиков для загрузки процессора, операций чтения / записи в секунду и транзакций в секунду. Transactions per second CPU Utilization Read / write operations

Мои ресурсы рабочей нагрузки следующие:

ресурсы: ограничения: процессор: 500 м памяти: 600 млн запросов: процессор: 200 м памяти: 500 м

1 Ответ

0 голосов
/ 10 февраля 2020

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

Если у вас есть нижний предел, то новым запросам / транзакциям придется ждать доступных connection.

Вы можете отслеживать текущие запросы (см., например, pg_stat_activity), чтобы обнаруживать такие проблемы.

Однако сервер базы данных должен иметь возможность обрабатывать количество соединений. Если вы используете сервер, предоставленный третьей стороной, он может иметь установленные ограничения. Если вы используете свой собственный сервер, его необходимо правильно настроить.

Обратите внимание, что для обработки большего количества соединений вашему серверу базы данных потребуется больше процессов и больше оперативной памяти. Кроме того, если они долго выполняют запросов (в отличие от транзакций), то вы, скорее всего, ограничены в ресурсах на сервере (часто связаны с вводом-выводом) и добавляете больше запросов, выполняющихся одновременно обычно не помогает с общей производительностью. Возможно, вы захотите посмотреть конфигурацию вашего сервера БД (buffers et c.) И, конечно, если вы еще этого не сделали, оптимизируйте свои запросы (убедитесь, что все они используют индексы). Другие pg_stat_* представления и EXPLAIN являются вашими друзьями здесь.

Если у вас есть длительные транзакции с большим количеством времени простоя, тогда могут помочь более параллельные соединения, хотя вам, возможно, придется задуматься, почему у вас такие длительные транзакции.

Подводя итог, вы должны сделать следующие шаги:

  • Проверить состояние сервера базы данных, используя pg_stat_activity и друзей.

  • Если у вас его еще нет, настройте мониторинг статистики ввода-вывода, процессора, памяти, подкачки, postgresql с течением времени. Это даст вам более четкое представление о том, что происходит на вашем сервере. Если у вас этого нет, вы просто работаете вслепую.

  • Если у вас есть длительные транзакции, убедитесь, что вы всегда правильно сбрасываете транзакции / соединения, в том числе при возникновении ошибок. Это довольно распространенная проблема с node.js веб-серверами. Убедитесь, что вы используете блоки try .. catch везде, где это необходимо.

  • Если есть какие-либо длительные запросы, убедитесь, что они должным образом оптимизированы (с использованием индексов). Если нет, сделайте все возможное, чтобы оптимизировать их. Это будет самый полезный шаг, который вы можете предпринять, если возникнет проблема.

  • Если они правильно оптимизированы и , у вас достаточно свободных ресурсов (ОЗУ, I / O ...), тогда вы можете рассмотреть возможность увеличения количества соединений. В противном случае это просто бессмысленно.

Редактировать

Поскольку вы сами не управляете базой данных, вы не обязательно будете иметь всю наглядность использования ресурсов.

Однако вы все равно можете:

  • Проверить pg_stat_activity. Уже одно это расскажет вам многое.
  • Проверка соединений / транзакций, которые хранятся, когда они не должны
  • Проверка правильности оптимизации запросов

GCP имеет максимальный предел одновременных подключений по умолчанию, установленный на 100 для экземпляров с 3,75 ГБ ОЗУ. Таким образом, вы действительно можете увеличить размер вашего пула. Но если какие-либо из перечисленных выше проблем присутствуют, вы просто задерживаете или перемещаете проблему немного дальше, поэтому начните с проверки и исправления их, если это необходимо.

...