Як правильно контролювати кількість підключень до бази даних PostgreSQL?

Я спробував використовувати сценарій Nagios для моніторингу кількості підключень до бази даних Postgres, і я дійшов до цієї проблеми: вони зараховуються як поточні відкриті з'єднання і вимірюються кожні 5 хвилин.

SELECT sum(numbackends) FROM pg_stat_database;

Але все ж, здається, це не вистачає величезної кількості короткочасних зв’язків, тому статистика далеко не реальна.

Я спробував запустити сценарій вручну, і я помітив великі зміни навіть між двома з'єднаннями, зробленими за кілька секунд один від іншого.

Як я міг отримати цю інформацію надійним чином? як-от max (connectios) траплявся протягом часового інтервалу.

postgresql performance monitoring

— сорїн
джерело

Загальна статистика з часом для з'єднань була б непоганою, але я не думаю, що PostgreSQL наразі їх збирає. Детальнішу інформацію див. У документах postgresql.org/docs/current/static/monitoring-stats.html .

— Крейг Рінгер

@CraigRinger, можливо, я міг налаштувати Postgres або клієнтів, щоб тримати проміжки довше, щоб відкрити з'єднання, тож я міг їх виміряти. У зв'язку з поточним налаштуванням у мене був один випадок, коли постгреси почали відмовлятися від з'єднання. Моніторинг не зміг цього виявити, оскільки це сталося протягом 5 хвилинного інтервалу, і воно перейшло від нижчого рівня попередження до вище критичного менш ніж за 5 хвилин. І це не була атака DoS.

— sorin

Так, це досить цікава проблема. Я настійно рекомендую поставити PgBouncerперед вашим екземпляром PostgreSQL, він буде чекати з'єднань, коли він занадто зайнятий, а не відхиляти їх. (Так, нерозумно, що PostgreSQL не може зробити це самостійно, але це не просте виправлення; див. Нескінченні дискусії у списках розсилки про вбудований пул).

— Крейг Рінгер

А що з підключеннями до журналу (за допомогою log_connections та log_disconnections) у файл реєстрації (наприклад, csvlog), а потім використовувати pgBadger або щось подібне, щоб витягнути це з журналу файлів?

— a_horse_with_no_name

@a_horse_with_no_name Добре. Ви навіть можете "хвіст" журналів з клієнтом, який щойно читає нові записи журналу, інтегруючись через відключення та з'єднуючись, щоб отримати звіт майже в реальному часі про пікові з'єднання протягом заданого періоду часу. Чесно кажучи, це не повинно бути таким складним. Одне з моїх завдань для проекту AXLE ( axleproject.eu ) - провести ще якийсь аудит, і я, можливо, зможу це вписати в нього ...

— Крейг Рінгер,

Краще використовувати засоби моніторингу робочого навантаження, наприклад, pgbadgerдля перевірки підключень до бази даних та загального навантаження. Це допоможе вам зрозуміти, які користувачі підключаються протягом скільки часу та які запити вони запускають. Для отримання інформації про встановлення та налаштування pgbadger див. Цю сторінку.

Якщо ви просто хочете перевірити кількість активних з'єднань, можете скористатися select count(*) from pg_stat_activity where state='active'

— Лохіт Гупта
джерело

Для цього можна використовувати розширення з local_preload_libraries.

Щось на зразок цього:

#include "postgres.h"
#include <string.h>

#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif

void _PG_init(void)
{
  SPI_connect();
  int ret = SPI_execute("UPDATE logon_logs SET logged = logged + 1", false, 0);
  SPI_finish();
}

/*
 * _PG_fini
 * Uninstall the hook.
 */
void _PG_fini(void)
{
}

Або замість цього ОНОВЛЕННЯ через NOTIFY

— Роман Ткачук
джерело

Спробуйте вдосконалити свою відповідь, пояснивши, як діяти далі.

— McNets