kill -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 для человека процесс запроса /поток больше не является смертным приговором.

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

22 голоса | спросил Banjer 7 PM00000090000001831 2012, 21:09:18

3 ответа


29

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

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

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

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

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

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

Кстати, если вы kill -9 postmaster, тогда удалите 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 бэкэнд.

ответил Craig Ringer 9 AM00000030000005331 2012, 03:57:53
28

I found the particular process via ps aux | grep postgres and ran kill -9 pid.
НЕТ! ПЛОХО! ОСТАВАЙТЕСЬ ОТ ВЕРНУТЬСЯ!

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

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

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

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

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

ответил voretaq7 7 PM00000090000000131 2012, 21:43:01
8

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

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

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

ответил Jeff Ferland 7 PM00000090000004031 2012, 21:20:40

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132