Pregunta matar a -9 un proceso de postgres


Una consulta SELECT de postgres se salió de control de nuestro servidor de DB y comenzó a consumir toneladas de memoria e intercambio hasta que el servidor se quedó sin memoria. He encontrado el proceso particular a través de ps aux | grep postgres y corrió kill -9 pid. Esto mató el proceso y la memoria se liberó como se esperaba. El resto del sistema y las consultas postgres parecían no verse afectadas. Este servidor ejecuta postgres 9.1.3 en SLES 9 SP4.

Sin embargo, uno de nuestros desarrolladores me reprendió por matar un proceso de postgres con kill -9, diciendo que va a acabar con todo el servicio de postgres. En realidad, no lo hizo. He hecho esto antes un puñado de veces y no he visto ningún efecto secundario negativo.

Dicho esto, y después de leer más, parece que kill pid Sin las banderas es la forma preferida de matar un proceso de postgres fuera de control, pero para otros usuarios de la comunidad de postgres, también suena como que postgres ha "mejorado" con el paso de los años, de modo que kill -9 en un proceso de consulta individual / hilo ya no es una sentencia de muerte.

¿Puede alguien iluminarme sobre la manera correcta de matar un proceso de postgres fuera de control, así como el uso desastroso (o benigno) de kill -9 ¿Está con Postgres estos días? Gracias por la perspicacia.


22
2017-08-07 17:09


origen




Respuestas:


voretaq7es responder cubre los puntos clave, incluyendo la forma correcta de terminar backends Pero me gustaría añadir un poco más de explicación.

kill -9 (es decir SIGKILL) nunca, nunca, nunca debe ser su primera opción por defecto. Debe ser su último recurso cuando el proceso no responde a sus solicitudes de cierre normales y SIGTERM (kill -15) no ha tenido ningún efecto. Eso es cierto de Pg y casi todo lo demás.

kill -9 le da al proceso muerto ninguna posibilidad de hacer ninguna limpieza en absoluto.

Cuando se trata de PostgreSQL, Pg ve un respaldo que termina por kill -9 como un choque hacia atrás. Sabe que el backend podría haber dañado la memoria compartida, porque podría haberla interrumpido a mitad de camino escribiendo una página en shm o modificando una, por ejemplo. termina y reinicia todos los otros backends cuando se da cuenta de que un backend se ha desvanecido repentinamente y ha salido con un código de error distinto de cero.

Verás esto reportado en los registros.

Si parece que no hace daño, eso se debe a que Pg está reiniciando todo después de la falla y su aplicación se está recuperando de las conexiones perdidas de forma limpia. Eso no lo hace una buena idea. Si no hay nada más probado en los choques de backend que en las partes de Pg que funcionan normalmente y son mucho más complicados / variados, las posibilidades de que haya un error al acecho en el manejo y recuperación de fallas de backend son mayores.

BTW, si tu kill -9 el administrador de correo luego retire postmaster.pid y empezar de nuevo sin asegurarse de que cada postgres el backend se ha ido, pueden pasar cosas muy malas. Esto podría suceder fácilmente si accidentalmente mató al administrador de correo en lugar de un servidor, vio que la base de datos se había caído, trató de reiniciarlo, eliminó el archivo "obsoleto" .pid cuando el reinicio falló y trató de reiniciarlo nuevamente. Esa es una de las razones por las que debes evitar agitar kill -9alrededor de Pg, y no debe eliminar postmaster.pid.

Una demostración:

Para ver exactamente que pasa cuando kill -9 un backend, pruebe estos sencillos pasos. Abra dos terminales, abra psql en cada uno, y en cada ejecución SELECT pg_backend_pid();. En otra terminal kill -9 Uno de los PIDs. Ahora corre SELECT pg_backend_pid(); en ambas sesiones de psql de nuevo. Note como ellos ambos perdido sus conexiones?

Sesión 1, que matamos:

$ 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)

Sesión 2, que fue daño colateral:

$ 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)

Ver cómo ambos sesiones fueron interrumpidas? Por eso no kill -9 un backend


29
2017-08-08 23:57



Todas las respuestas muy buenas aquí, y muy humillante podría agregar. Podría marcarlos todos como aceptados, pero @Craig Ringer tiene algunos puntos adicionales aquí y realmente los impulsa a su hogar. Gracias de nuevo SF por limpiarme de mis malos hábitos! - Banjer
@Craig: Qué excelente respuesta; y para incluir una demostración, me gustaría poder votar este 100x. Soy un desarrollador de software que trabaja con PG diariamente y desde los 6.x días, ¡su respuesta es acertada! ¡Bonito! - Kilo
Buena respuesta. Un apéndice: si tiene un proceso de back-end que absolutamente no morirá, no con pg_terminate_backend, no con un reinicio de la pila del servidor, no con cualquier cosa, puede anularlo como desee, pero asegúrese de tener una copia de seguridad activa de su base de datos. Puedes hacerlo de dos maneras: puedes usar pg_basebackup o similar (o simplemente rsync y pg_start\stop_backup) para hacer una copia de seguridad de su directorio de datos (pruebe las copias de seguridad antes de continuar), o puede usar pg_dump[all] para salvar sus datos. Solo entonces deberías considerar kill -9, o un reinicio, o lo que sea. - Zac B
@ZacB Sí, y si lo matas, asegúrate todos los traseros mueren. Más vitalmente, Nunca borrar postmaster.pid. Siempre. - Craig Ringer


I found the particular process via ps aux | grep postgres and ran kill -9 pid.
¡NO! ¡MALO! ¡A PASEO DEL BACKEND!

En serio: no mates los backends de Postgres de esa manera: pueden suceder TERRIBLES cosas (incluso con todas las mejoras de estabilidad que se han realizado desde los 7.x días) que pueden destrozar toda tu base de datos, y tu desarrollador tiene toda la razón para masticar Usted fuera por hacer esto.

Hay, de hecho, una forma bendecida y aprobada de hacer esto desde Postgres - Está incluso en el Manual de postgres A pesar de que SO post hace un mejor trabajo explicándolo ...

SELECT pg_cancel_backend(pid)
Envía una cancelación (SIGINT) señal al backend especificado, que cancela la consulta actualmente en ejecución.

select pg_terminate_backend(pid)
Envía una terminación (SIGTERM) señal al backend especificado, que cancela la consulta y anula el backend (interrumpiendo su conexión).

Los ID de backend se pueden obtener de la pg_stat_activity mesa (o ps)


28
2017-08-07 17:43



En caso de que alguien se pregunte por las cosas terribles, dado que kill -9 no es diferente a apagar repentinamente el sistema en lo que respecta al proceso interrumpido: Pg es muy tolerante a los choques de back-end (como un kill -9) y nunca debe haber corrupción de datos. Ahí será ser corrupto si matas al administrador de correos, elimine postmaster.pid y reinícielo sin matar también a todos los servidores. Ese será destruye tu base de datos, pero toma mucho más que solo un kill -9 a un backend. kill -9 no le da tiempo al administrador de correo para matar a los backends, por lo que es peligroso. - Craig Ringer
... como un caso de consulta de emergencia que tuve la semana pasada. Corrompieron gravemente su base de datos, perdieron dos días de trabajo porque sus copias de seguridad fallaron (y no realizaron pruebas automáticas de sus restauraciones), se suspendieron durante 48 horas. No borrar postmaster.pid. - Craig Ringer


Matar un proceso de cliente PostgreSQL debería estar bien. Matar un proceso de daemon PostgreSQL puede hacer que te regañen.

Como los demonios de SQL también tienen controles de proceso internos, la forma preferida es intentar usar ese canal primero.

Ver Detener (largo) la consulta SQL en PostgreSQL ... desde StackOverflow.


8
2017-08-07 17:20



kill -9 Nunca debería ser su opción predeterminada de todos modos, es un último recurso. Enviar una SIGTERM con kill -TERM o simple kill y si el destinatario no responde después de un tiempo, solo entonces debes considerar kill -KILL (kill -9). - Craig Ringer