postgres 프로세스 종료 -9

postgres SELECT 쿼리가 DB 서버에서 제어 할 수 없었고 많은 메모리를 소모하기 시작했으며 서버에 메모리가 부족해질 때까지 스왑했습니다. 를 통해 특정 프로세스를 발견 ps aux | grep postgres하고 실행했습니다 kill -9 pid. 이로 인해 프로세스가 중단되고 메모리가 예상대로 해제되었습니다. 나머지 시스템 및 postgres 쿼리는 영향을받지 않은 것으로 보입니다. 이 서버는 SLES 9 SP4에서 postgres 9.1.3을 실행하고 있습니다.

그러나 개발자 중 한 명이 postgres 프로세스를 kill -9종료하여 전체 postgres 서비스를 중단시킬 것이라고 말했습니다. 실제로는 그렇지 않았습니다. 나는 이것을 몇 번 전에 해왔으며 부작용을 보지 못했습니다.

그렇기 때문에 더 자세히 읽은 후에 kill pid는 깃발이 없으면 런 어웨이 postgres 프로세스를 죽이는 선호되는 방법이지만 postgres 커뮤니티의 다른 사용자마다 postgres가 수년 동안 "더 좋아졌다"고 들립니다. kill -9개별 쿼리 프로세스 / 스레드에서 더 이상 사형 선고가 아닙니다.

누군가 kill -9Postgres에서 비참한 (또는 양성) 사용 이 요즘 Postgres와 얼마나 다른지에 따라 도망가는 postgres 프로세스를 죽일 수있는 올바른 방법을 가르쳐 줄 수 있습니까 ? 통찰력에 감사드립니다.

voretaq7 의 답변 은 백엔드를 종료 하는 올바른 방법을 포함하여 핵심 요점을 다루지 만 조금 더 설명하고 싶습니다.

kill -9(즉, SIGKILL) 절대로 당신의 첫 번째 선택이되어서는 안됩니다 . 프로세스가 정상적인 종료 요청에 응답하지 않고 SIGTERM( kill -15)가 효과가없는 경우 최후의 수단이어야합니다 . 그것은 Pg와 다른 모든 것의 사실입니다.

kill -9 종료 된 프로세스가 전혀 정리할 기회를 제공하지 않습니다.

PostgreSQL과 관련하여 Pg는 kill -9백업 된 충돌로 종료 된 백업을 확인합니다 . 백엔드가 공유 메모리를 손상 시켰을 수도 있습니다. 예를 들어 페이지를 shm에 쓰거나 수정하는 등의 과정을 절반으로 중단했을 수 있기 때문에 백엔드가 갑자기 사라 졌다는 것을 알게되면 다른 모든 백엔드를 종료하고 다시 시작합니다. 0이 아닌 오류 코드로 종료되었습니다.

로그에이 내용이보고됩니다.

손상되지 않은 것으로 보이면 충돌 후 Pg가 모든 것을 다시 시작하고 응용 프로그램이 손실 된 연결을 깨끗하게 복구하기 때문입니다. 그것은 좋은 생각이 아닙니다. 백엔드 충돌이 Pg의 정상 작동 부분보다 잘 테스트되지 않고 훨씬 더 복잡하고 다양하면 백엔드 충돌 처리 및 복구에 버그가 발생할 가능성이 더 높습니다.

BTW, kill -9포스트 마스터 가 postmaster.pid모든 postgres백엔드가 사라지지 않도록 제거 하고 다시 시작하면 매우 나쁜 일이 발생할 수 있습니다 . 백엔드 대신 우발적으로 포스트 마스터를 종료하고 데이터베이스가 다운 된 것을보고 재시작을 시도한 후 재시작에 실패했을 때 "stale".pid 파일을 제거한 후 다시 시작하려고하면이 문제가 쉽게 발생할 수 있습니다. 이것이 kill -9Pg를 흔들지 말아야하는 이유 중 하나이며 삭제해서는 안됩니다 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 일 이후에 이루어진 모든 안정성 향상으로도) DB 전체를 손상시킬 수 있으며 개발자는 씹을 권리가 있습니다 이 일을 해주셔서

실제로 Postgres 내 에서이 작업을 수행하는 축복되고 승인 된 방법이 있습니다 .Postgres 매뉴얼 에서도 SO 포스트가 더 잘 설명 할 수 있지만 ...

SELECT pg_cancel_backend(pid)
SIGINT지정된 백엔드에 취소 ( ) 신호를 전송 하여 현재 실행중인 쿼리를 취소합니다.

select pg_terminate_backend(pid)
종료 ( SIGTERM) 신호를 지정된 백엔드로 전송 하여 쿼리를 취소하고 백엔드를 중단합니다 (연결을 끊음).

백엔드 ID는 pg_stat_activity표 에서 얻을 수 있습니다 (또는 ps).

PostgreSQL 클라이언트 프로세스를 종료하는 것이 좋습니다. PostgreSQL 데몬 프로세스를 종료하면 꾸짖을 수 있습니다.

SQL 데몬에도 내부 프로세스 제어 기능이 있으므로 선호하는 방법은 해당 채널을 먼저 사용하는 것입니다.

StackOverflow의 PostgreSQL에서 SQL 쿼리 실행 중지 (장기)를 참조 하십시오 .