nginx 신호 세트 예시 분석

Scenario Reproduction

아래에서는 기본 nginx를 사용하여 fedora26이 설치된 가상 머신에서 이 프로세스를 재현하겠습니다. 제가 사용하는 nginx 버전은 최신 1.13.4입니다.

먼저 nginx를 시작하세요

둘 다 볼 수 있습니다. 마스터와 작업자가 이미 실행 중입니다.

그런 다음 nginx 코어가 이 신호를 수신하면 sigusr2 신호를 마스터에 보냅니다.

새 마스터와 마스터가 포크한 워커가 이미 실행 중인 것을 볼 수 있습니다. 이때 우리는 이 신호를 받은 후 이전 마스터에게 sigquit을 보냅니다. , 따라서 이전 마스터의 작업자 프로세스가 종료됩니다.

이때 이전 마스터, 새 마스터 및 새 마스터의 작업자만 실행되며 이는 온라인 작업 상황과 유사합니다. 그때에.

그런 다음 중지 명령을 사용합니다.

새 마스터와 해당 작업자가 종료된 반면 이전 마스터는 여전히 실행 중이며 작업자를 생성했습니다. 당시 온라인 상황은 이랬다.

사실 이 현상은 nginx 자체의 설계와 관련이 있습니다. 이전 마스터가 새 마스터를 포크할 준비가 되면 nginx.pid 파일 이름을 nginx.pid.oldbin으로 바꾼 다음 새 마스터를 포크합니다. 마스터는 새 nginx.pid를 생성합니다. 이 파일은 새 마스터의 pid를 기록합니다. nginx는 핫 업데이트가 완료된 후 이전 마스터의 임무가 거의 종료되고 언제든지 종료되므로 모든 후속 작업은 새 마스터가 인수해야 한다고 믿습니다. 물론, 이전 마스터를 종료하지 않고 새 마스터에 sigusr2를 전송하여 또 다른 핫 업데이트를 시도하는 것은 유효하지 않습니다. 새 마스터는 이 신호를 무시하고 자체 작업을 계속합니다.

문제 분석

더 불행한 점은 위에서 언급한 lua 테이블, 이를 정의하는 lua 파일이 이미 luajit에 의해 메모리에 로드되어 init_by_lua 후크를 실행할 때 바이트 코드로 컴파일되었다는 것입니다. 이 루아 테이블이 있어야 합니다. 로드되는 루아 코드 부분이 이전 버전이기 때문입니다.

init_by_lua 중에는 테이블을 인덱싱하는 Lua 코드가 사용되지 않습니다. 이 코드는 작업자 프로세스에 로드됩니다. 이때 프로젝트 디렉터리에 있는 코드는 모두 최신이므로 작업자 프로세스에서는 최신 코드를 모두 로드합니다. 이러한 작업자 프로세스가 관련 요청을 처리하면 Lua 런타임 오류가 발생하고 외부 표현은 해당 http 500이 됩니다.

이 교훈을 흡수한 후에는 nginx 서비스를 보다 합리적으로 종료해야 합니다. 따라서 보다 합리적인 nginx 서비스 시작 및 종료 스크립트가 필요하며, 인터넷에 유통되는 일부 스크립트에서는 이러한 현상을 다루지 않으며, nginx에서 제공하는 공식 스크립트를 참조해야 합니다.

이 코드는 nginx 공식 /etc/init.d/nginx에서 인용되었습니다.

nginx 신호 세트

다음으로 nginx 신호 세트를 종합적으로 정리하겠습니다. 여기서는 소스 코드 세부 사항을 다루지 않습니다. 관심 있는 학생들은 스스로 관련 소스 코드를 읽을 수 있습니다.

마스터 프로세스에 신호를 보내는 방법에는 두 가지가 있습니다. 하나는 nginx -s 신호를 사용하는 것이고, 다른 하나는 kill 명령을 통해 수동으로 보내는 것입니다.

첫 번째 방법의 원리는 새로운 프로세스를 생성하는 것입니다. 이 프로세스는 nginx.pid 파일을 통해 마스터 프로세스의 pid를 얻은 다음 해당 신호를 마스터에 보낸 다음 종료합니다.

두 번째 방법에서는 nginx -s 신호와 실제 신호의 매핑을 이해해야 합니다. 다음 표는 해당 매핑 관계입니다.

작동 신호
sigup 다시 로드
sigusr1 다시 열기
stop sigterm
quit sigquit
hot update sigusr2 & sigwinch & sigquit
stop 대 quit

stop 강제 종료 요구 사항을 나타내는 sigterm 신호를 보냅니다. , 종료는 sigquit로 전송됩니다. 이는 정상적으로 종료한다는 의미입니다. 구체적인 차이점은 작업자 프로세스가 sigquit 메시지를 수신한 후(신호가 직접 전송되지 않으므로 대신 메시지가 사용됨) 청취 소켓을 닫고 현재 유휴 연결(선점할 수 있는 연결)을 닫는다는 것입니다. ), 그런 다음 미리 처리합니다. 모든 타이머 이벤트는 마지막에 종료됩니다. 특별한 경우가 아니면 stop 대신 quit을 사용해야 합니다.

reload

sigup을 받은 후 마스터 프로세스는 구성 파일을 다시 구문 분석하고 공유 메모리 및 기타 일련의 작업을 적용한 다음 새로운 작업자 프로세스 배치를 생성하고 마지막으로 sigquit 해당 메시지를 이전 작업자 프로세스를 완료하고 마침내 다시 시작 작업을 원활하게 실현했습니다.

재오픈

마스터 프로세스는 sigusr1을 수신한 후 열려 있는 모든 파일(예: 로그)을 다시 열고 sigusr1 정보를 각 작업자 프로세스에 보냅니다. 작업자 프로세스는 신호를 수신한 후 동일한 작업을 수행합니다. 예를 들어, nginx는 공식적으로 솔루션을 제공합니다:

여기서는 sleep 1이 필요합니다. sigusr1 메시지를 작업자 프로세스로 보내는 마스터 프로세스와 실제로 access.log를 다시 여는 작업자 프로세스 사이에 있기 때문입니다. , 일정 기간 동안 작업자 프로세스는 여전히 access.log.0 파일에 로그를 기록합니다. Sleep 1s로 access.log.0 로그 정보의 무결성을 보장합니다(Sleep 없이 직접 압축을 수행할 경우 로그 유실이 발생할 가능성이 높습니다).

hot update

때로는 바이너리 핫 업데이트를 수행해야 합니다. nginx에는 설계 중에 이 기능이 포함되어 있지만 nginx에서 제공하는 명령줄을 통해서는 수동으로 신호를 보내야 합니다.

위의 문제 재발을 통해 먼저 sigusr2를 현재 마스터 프로세스로 전송해야 합니다. 그런 다음 마스터는 nginx.pid의 이름을 nginx.pid.oldbin으로 바꾼 다음 새 프로세스를 포크합니다. 하나의 프로세스에서 새 프로세스는 execve 시스템 호출을 사용하여 현재 프로세스 이미지를 새 nginx elf 파일로 바꾸고 새 마스터 프로세스가 됩니다. 새 마스터 프로세스가 시작된 후 구성 파일 구문 분석 및 기타 작업을 수행한 다음 새 작업자 프로세스를 분기하여 작업을 시작합니다.

그런 다음 sigwinch 신호를 이전 마스터에 보내면 이전 마스터 프로세스가 sigquit 메시지를 작업자 프로세스에 보내 작업자 프로세스가 종료됩니다. sigwinch 및 sigquit를 마스터 프로세스에 보내면 작업자 프로세스가 종료되지만 전자를 사용하면 마스터 프로세스도 종료되지 않습니다.

마지막으로 이전 마스터 프로세스가 임무를 완료했다고 느끼면 sigquit 신호를 보내고 종료되도록 할 수 있습니다.

작업자 프로세스가 마스터의 신호 메시지를 처리하는 방법

실제로 마스터 프로세스는 kill 기능을 사용하지 않고 파이프를 통해 구현된 nginx 채널을 사용하여 작업자 프로세스와 통신합니다. 파이프 끝(신호 정보 등)에 따라 작업자 프로세스는 다른 쪽 끝에서 정보를 수신합니다. nginx 채널 이벤트는 작업자 프로세스가 막 시작될 때 이벤트 스케줄러(예: epoll, kqueue)에 추가됩니다. 마스터에서 전송된 데이터, 즉 이벤트 스케줄러에서 알림을 받을 수 있습니다.

nginx가 이렇게 설계된 데에는 이유가 있습니다. 뛰어난 역방향 프록시 서버로서 nginx는 극도의 고성능을 추구하며, 신호 처리기는 작업자 프로세스의 실행을 중단하여 모든 이벤트를 일정 시간 동안 중단시킵니다. 성능이 확실히 손실됩니다.

많은 사람들은 마스터 프로세스가 작업자 프로세스에 정보를 전송하면 작업자 프로세스가 해당 작업으로 즉시 응답할 것이라고 생각할 수 있습니다. 그러나 작업자 프로세스는 nginx를 호출할 때 지속적으로 매우 바빠집니다. 채널 이벤트 핸들러 이후 nginx는 일부 플래그만 처리합니다. 이러한 작업은 일련의 이벤트 예약이 완료된 후에 실제로 실행됩니다. 따라서 그 사이에 시간 창이 있습니다. 특히 비즈니스가 복잡하고 트래픽이 많을 경우 이 창이 확대될 수 있습니다. 이것이 nginx에서 공식적으로 제공하는 로그 절단 계획에 절전 1이 필요한 이유입니다.

물론, 마스터 프로세스를 우회하고 작업자 프로세스에 직접 신호를 보낼 수도 있습니다. 작업자가 처리할 수 있는 신호는

signal effect
sigint forceexit
sigterm forceexit
sigquit Graceful Exit
sigusr1 파일 다시 열기입니다.

위 내용은 nginx 신호 세트 예시 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!