убить -9 процесс postgres

Запрос postgres SELECT вышел из-под контроля на нашем сервере БД и начал поглощать тонны памяти и выполнять обмен, пока на сервере не закончилась память. Я нашел конкретный процесс через ps aux | grep postgresи побежал kill -9 pid. Это убило процесс, и память освободилась, как и ожидалось. Остальная часть системы и запросы postgres оказались незатронутыми. Этот сервер работает с Postgres 9.1.3 на SLES 9 SP4.

Тем не менее, один из наших разработчиков разжевал меня за то, что я убил процесс postgres kill -9, заявив, что он уничтожит весь сервис postgres. На самом деле это не так. Я делал это раньше несколько раз и не видел никаких негативных побочных эффектов.

С учетом вышесказанного и после прочтения кажется, что kill pidбез флагов это предпочтительный способ убить безудержный процесс postgres, но для других пользователей в сообществе postgres также звучит так, что postgres «поправился» за эти годы, так что kill -9по отдельному запросу процесс / поток больше не является смертным приговором.

Может ли кто-нибудь рассказать мне о правильном способе уничтожения безудержного процесса postgres, а также о том, насколько пагубным (или доброкачественным) kill -9является использование с Postgres в эти дни? Спасибо за понимание.

voretaq7 «сек ответ охватывает ключевые моменты, в том числе правильного способа прекратить движки , но я хотел бы добавить немного больше объяснений.

kill -9(то есть SIGKILL) никогда не должно быть вашим выбором по умолчанию . Это должно быть вашим последним средством, когда процесс не отвечает на свои обычные запросы на отключение и a SIGTERM( kill -15) не имеет никакого эффекта. Это верно для Pg и почти всего остального.

kill -9 не дает убитому процессу никакого шанса сделать какую-либо очистку вообще.

Когда дело доходит до PostgreSQL, Pg видит резервную копию, которая заканчивается kill -9как аварийная остановка . Он знает, что бэкэнд мог испортить разделяемую память - потому что вы могли прервать ее на полпути, например, записав страницу в shm или изменив ее - поэтому он завершает работу и перезапускает все остальные бэкэнды, когда замечает, что бэкэнд внезапно исчез и вышел с ненулевым кодом ошибки.

Вы увидите это в журналах.

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

Кстати, если вы kill -9почтмейстер, затем удалите postmaster.pidи запустите его снова, не убедившись, что все postgresбэкэнды исчезли, могут произойти очень плохие вещи . Это может легко произойти, если вы случайно убили администратора почты вместо бэкэнда, увидели, что база данных вышла из строя, попытались перезапустить ее, удалили «устаревший» файл .pid при сбое перезапуска и попытались перезапустить его снова. Это одна из причин, по которой вы должны избегать размахивать kill -9вокруг Pg и не должны удалять postmaster.pid.

Демонстрация:

Чтобы увидеть, что именно происходит, когда вы kill -9бэкэнд, попробуйте эти простые шаги. Откройте два терминала, откройте psql в каждом и в каждом прогоне SELECT pg_backend_pid();. В другом терминале kill -9один из PID. Теперь SELECT pg_backend_pid();снова запустите обе сессии psql. Обратите внимание, как они оба потеряли свои связи?

Сессия 1, которую мы убили:

$ psql regress
psql (9.1.4)
Type "help" for help.

regress=# select pg_backend_pid();
 pg_backend_pid 
----------------
           6357
(1 row)

[kill -9 of session one happens at this point]

regress=# select pg_backend_pid();
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
regress=# select pg_backend_pid();
 pg_backend_pid 
----------------
           6463
(1 row)

Сессия 2, в которой был побочный ущерб:

$ psql regress
psql (9.1.4)
Type "help" for help.

regress=# select pg_backend_pid();
 pg_backend_pid 
----------------
           6283
(1 row)

[kill -9 of session one happens at this point]

regress=# select pg_backend_pid();
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
regress=# select pg_backend_pid();
 pg_backend_pid 
----------------
           6464
(1 row)

Видите, как обе сессии были прерваны? Вот почему вы не kill -9бэкэнд.

I found the particular process via ps aux | grep postgres and ran kill -9 pid.
НЕТ! ПЛОХО! ШАГ ВНЕ ОТ БАКЕНДА!

Серьезно - не убивайте бэкэнды Postgres таким образом - могут произойти УЖАСНЫЕ вещи (даже со всеми улучшениями стабильности, которые были сделаны со времен 7.x), которые могут испортить всю вашу БД, и ваш разработчик совершенно правильно жует Вы за это.

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

SELECT pg_cancel_backend(pid)
Посылает SIGINTсигнал cancel ( ) указанному бэкэнду, который отменяет текущий запущенный запрос.

select pg_terminate_backend(pid)
Посылает SIGTERMсигнал terminate ( ) указанному бэкэнду, который отменяет запрос и прерывает бэкэнд (разрывая его соединение).

Идентификаторы бэкэнда можно получить из pg_stat_activityтаблицы (или ps)

Убить процесс клиента PostgreSQL должно быть хорошо. Убийство демона PostgreSQL может вас ругать.

Поскольку демоны SQL также имеют внутренние средства управления процессами, предпочтительным способом является сначала попытаться использовать этот канал.

См. Остановить (длинный) выполнение SQL-запроса в PostgreSQL ... из StackOverflow.