Первым шагом при внесении изменений или чтении некоторой информации из банка данных PostgreSQL является установление соединений. С другой стороны, каждая ссылка создавала накладные расходы, связанные с использованием процедуры и хранилища. Вот почему устройство с минимальными ресурсами (чтение, хранилище, оборудование) может поддерживать ограниченную совокупность подключений. Как только ограниченный агрегат выходит далеко за пределы определенной точки, он должен продолжать выдавать ошибки или отказывать в соединениях. В PostgreSQL.conf PostgreSQL неплохо справляется с ограничением ссылок. В этом руководстве мы рассмотрим различные формы состояний, которые могут иметь ссылки PostgreSQL. Мы покажем вам, как определить, активна ли ссылка или была неактивна в течение длительного времени, в этом случае ее можно отключить, чтобы освободить ссылки и ресурсы.
Подключиться к серверу
Вначале убедитесь, что pgAdmin4 полностью установлен в вашей компьютерной системе. Откройте его из ваших приложений. Вы должны соединить его с локальным хостом, указав пароль.
После подключения к корневому локальному хосту подключите его к серверу PostgreSQL. Введите пароль для подключения пользователя PostgreSQL 13 Postgres. Нажмите кнопку ОК, чтобы продолжить.
Теперь вы подключены к серверу PostgreSQL 13. Вы можете увидеть список баз данных, находящихся на сервере, как показано на рисунке ниже. База данных Postgres — это база данных по умолчанию, созданная во время установки PostgreSQL, в то время как «тестовая» база данных была создана пользователем после установки.
Состояния подключения
Если связь с PostgreSQL установлена, она может выполнять различные действия, которые приводят к переходам между состояниями. Следует принять рациональное решение о том, работает ли ссылка или она оставалась неактивной / неиспользованной, в зависимости от состояния и продолжительности нахождения в каждом состоянии. Важно отметить, что до тех пор, пока приложение намеренно не закроет соединение, оно будет продолжать работать, тратя ресурсы еще долгое время после отключения клиента. Существует 4 возможных состояния подключения:
- Активно: это означает, что ссылка установлена и работает.
- Бездействие: это означает, что ссылка неактивна, поэтому мы должны вести учет их в зависимости от того, как долго они не использовались.
- Бездействие (в транзакции): это означает, что серверная часть выполняет запрос, хотя на самом деле она простаивает и, возможно, ожидает ввода от конечного клиента.
- Ожидание в транзакции (прервано): это состояние эквивалентно бездействию в процессе. Однако одно из заявлений завершилось ошибкой. Его можно отследить в зависимости от того, как долго он простаивал.
Определите состояния подключения
Таблицы каталога PostgreSQL предоставляют встроенное представление pg_stat_activity для проверки статистики о том, что делает ссылка или сколько времени она находилась в этом состоянии. Чтобы проверить всю статистику по каждой базе данных и каждому состоянию соединения, откройте инструмент запроса и выполните следующий запрос:
>> SELECT * FROM pg_stat_activity;
Запрос был реализован плодотворно, и отметка о выполнении показана.
Когда вы проверите его сторону вывода данных, вы найдете таблицу с несколькими столбцами, как показано ниже. Вы можете проверить состояния соединений, проверив значения поля «состояние».
Чтобы упростить вывод и иметь четкое представление о соединениях, их состояниях, пользователях и серверах в этих состояниях, вы должны выполнить измененный ниже запрос в инструменте запросов. Этот запрос показывает только 5 полей записей для подключений и конкретные данные о них. Столбец «pid» обозначает идентификатор процесса. Столбец «состояние» содержит состояния процессов. А также столбец usename определяет пользователя, который работал над определенным процессом. В столбце «имя данных» указано имя базы данных, в которой выполнялась транзакция. Столбец «datid» обозначает идентификатор базы данных.
>> SELECT pid, state, usename datname, datid, from pg_stat_activity;
На выходе всего записано 8 процессов. Столбец «состояние» показывает, что сейчас работают только 3 процесса. Один хранится в базе данных по умолчанию «Postgres», а два других — в базе данных «test». В то же время пользователь Postgres выполнял эти процессы.
Определите незанятые соединения
«Состояние» кажется единственным значением, которое мы ищем в упомянутых выше результатах. Мы будем использовать эту информацию, чтобы определить, какие процессы или запросы в каком состоянии находятся, а затем копать глубже. Мы можем сократить количество деталей, которые мы ищем, уточнив запрос, что позволит нам подготовить вмешательство в это конкретное соединение. Также мы могли бы сделать это, выбрав только незанятые PID с помощью предложения WHERE и состояний для этих PID. Мы также должны следить за тем, как долго ссылка была неактивной, и следить за тем, чтобы пренебрегаемые ссылки не растратили наши ресурсы. В результате мы будем использовать перефразированную ниже команду, чтобы отображать только записи, относящиеся к процессам, которые в данный момент простаивают:
>> SELECT pid, usename, usesysid, datid, datname, application_name, backend_start,state_change, state FROM pg_stat_activity WHERE state = ‘idle’;
Запрос получил только 2 записи данных, в которых состояние было «неактивным», с использованием предложения WHERE. Результат показывает 2 незанятых процесса с определенной информацией о них.
Убить простаивающее соединение
После выявления незанятых соединений теперь пора их убить. После того, как мы сократили процесс либо в состоянии ожидания, либо в неактивном состоянии на гораздо более длительный срок, мы могли бы использовать простую команду, чтобы легко завершить внутренний механизм, не нарушая работу сервера. Мы должны предоставить идентификатор процесса в запросе в функции завершения.
>> SELECT pg_terminate_backend(7408);
Процесс был великолепно убит.
Теперь проверьте оставшиеся незанятые соединения из запроса ниже.
>> SELECT datid, usename, datname, pid, state FROM pg_stat_activity WHERE state = ‘idle’;
В выходных данных отображается только 1 оставшийся процесс, который бездействует.
Заключение
Не пропустите ни одного шага, чтобы эффективно отключить неактивные соединения из базы данных PostgreSQL.
