# 서비스 nginx 재시작
* nginx 재시작
# ps -ef --forest | grep nginx
루트 32475 1 0 13:36 ? 00:00:00 nginx: 마스터 프로세스 /usr/sbin/nginx
-c /etc/nginx/nginx.conf
nginx 32476 32475 0 13:36 ? 00:00:00 _ nginx: 작업자 프로세스
nginx 32477 32475 0 13:36 ? 00:00:00 _ nginx: 작업자 프로세스
nginx 32479 32475 0 13:36 ? 00:00:00 _ nginx: 작업자 프로세스
nginx 32480 32475 0 13:36 ? 00:00:00 _ nginx: 작업자 프로세스
nginx 32481 32475 0 13: 36 ? 00:00:00 _ nginx: 캐시 관리자 프로세스
nginx 32482 32475 0 13:36 ? 00:00:00 _ nginx: 캐시 로더 프로세스
이 쿼드 코어 서버에서 메인 스레드는 하드 디스크 캐시를 관리하는 데 사용되는 4개의 작업자 프로세스와 캐시 도우미 프로세스 집합을 생성합니다.
프레임워크가 왜 그렇게 중요한가요?
모든 Unix 애플리케이션의 기본은 스레드 또는 프로세스입니다. Linux 운영 체제의 경우 스레드와 프로세스는 거의 동일합니다. 스레드 간의 메모리가 공유된다는 것입니다. 스레드 또는 프로세스는 운영 체제가 단일 CPU 코어에서 실행되도록 예약하는 독립적인 명령 집합입니다. 많은 복잡한 애플리케이션이 두 가지 이유로 여러 스레드 또는 프로세스에서 병렬로 실행됩니다.
애플리케이션은 컴퓨터의 여러 CPU 코어를 동시에 사용할 수 있습니다.
스레드와 프로세스는 병렬로 작동하기 쉽습니다. 다중 연결
프로세스와 스레드는 메모리 및 기타 운영 체제 리소스, 코어 스위칭(Wapped on/off)과 같은 리소스를 소비합니다. 코어) ) (이 작업을 컨텍스트 전환이라고 합니다). 오늘날의 서버는 수천 개의 작은 활성 스레드 또는 프로세스를 동시에 처리해야 합니다. 메모리가 고갈되거나 읽기 및 쓰기 로드가 너무 높아지면 이로 인해 대규모 컨텍스트 전환이 발생하고 성능이 심각하게 저하됩니다.
일반적인 설계 아이디어는 네트워크 애플리케이션이 각 연결에 스레드나 프로세스를 할당하는 것입니다. 이러한 유형의 프레임워크는 간단하고 구현하기 쉽지만 수천 개의 연결을 동시에 처리할 때 확장하기가 어렵습니다.
NGINX는 어떻게 작동하나요?
NGINX는 예측 프로세스 모델을 활용하여 사용 가능한 하드웨어 리소스를 예약합니다.
메인 프로세스는 구성 파일 읽기, 포트 바인딩 등과 같은 권한 있는 작업을 처리할 뿐만 아니라 작은 하위 프로세스 집합(다음 세 가지 유형의 프로세스)을 생성합니다.
시작 시 캐시 로딩 서버 프로세스는 하드 디스크에서 메모리로 캐시를 로딩한 후 종료됩니다. 일정이 보수적이므로 리소스 오버헤드가 낮습니다
캐시 관리 프로세스가 정기적으로 실행되어 하드 디스크 캐시의 항목을 지정된 크기로 정리합니다
작업자 프로세스는 네트워크 연결 처리, 하드 디스크 읽기 및 쓰기 작업, 업스트림 서버 통신 등 모든 작업을 담당합니다.
권장 사항 NGINX 구성은 하드웨어 리소스의 효과적인 활용을 보장하기 위해 하나의 작업자 프로세스가 하나의 CPU 코어에 해당합니다.
worker_processes auto;
NGINX가 서비스를 시작하면 작업자 프로세스만 사용 중이며 각 작업자 프로세스는 비차단 방식으로 여러 연결을 처리하여 컨텍스트 전환 횟수를 줄입니다. .
각 작업자 프로세스는 단일 스레드로 독립적으로 실행되며 새로운 연결을 획득하고 처리하는 역할을 담당합니다. 프로세스는 캐시 데이터, 세션 지속성 데이터 및 기타 공유 리소스와 같은 공유 메모리를 통해 통신합니다. NGINX 1.7.11 이상 버전에는 작업자 프로세스가 차단 작업을 수행하는 선택적 스레드 풀이 있습니다. 자세한 내용은 "Nginx, 스레드 풀을 도입하여 성능을 9배 향상"을 참조하세요. NGINX Plus 사용자의 경우 이러한 새로운 기능이 올해 릴리스 7에 나타날 것입니다.
NGINX 내부 작업 프로세스
각 NGINX 작업자 프로세스는 구성 파일에 의해 초기화되며 기본 프로세스는 청취 소켓 세트를 제공합니다.
작업자 프로세스는 소켓 수신 이벤트(accept_mutex 및 커널 소켓 샤딩)로 시작됩니다. 이벤트는 새 연결에 의해 초기화된 다음 이러한 연결이 상태 시스템으로 전달됩니다. HTTP 상태 머신이 가장 일반적으로 사용되지만 NGINX는 스트림 기반 상태 머신과 통신 프로토콜 기반 상태 머신(SMTP, IMAP 및 POP3)도 구현합니다.
상태 머신은 NGINX에 각 요청을 처리하는 방법을 알려주는 중요한 지침 세트입니다. . 많은 웹 서버는 NGINX의 상태 머신과 동일한 기능을 가지고 있습니다. 차이점은 구현에 있습니다.
스케줄링 상태 머신
상태 머신은 다음과 같습니다. 체스 아래에서 단일 HTTP 트랜잭션은 체스 게임과 같습니다. 체스판의 한쪽 끝에는 매우 빠르게 결정을 내리는 그랜드마스터와 같은 웹 서버가 있고, 다른 쪽에는 상대적으로 느린 네트워크를 통해 사이트나 애플리케이션에 액세스하는 웹 브라우저인 원격 클라이언트가 있습니다.
그러나 게임 규칙은 매우 복잡할 수 있습니다. 예를 들어 네트워크 서비스는 제3자, 인증 서버 또는 심지어 제3자와 통신해야 할 수도 있습니다. 게임 규칙을 확장하기 위한 서버의 파티 모듈.
차단 상태 머신
이전 설명, 프로세스 또는 스레드는 운영 체제가 특정 CPU 코어에서 실행되도록 예약하는 일련의 명령입니다. 대부분의 웹 서버와 웹 애플리케이션은 하나의 연결을 처리하는 하나의 프로세스 또는 하나의 연결을 처리하는 하나의 스레드 또는 명령을 포함하는 스레드가 게임 전체에 참여하는 모델에 따라 체스 게임을 합니다. 이 기간 동안 서버에서 실행 중인 프로세스는 대부분 차단됩니다. 즉, 클라이언트가 다음 이동을 완료할 때까지 기다립니다.
네트워크 서버 프로세스는 소켓에서 새로운 연결을 수신합니다. . 이 새로운 게임 연결은 클라이언트에 의해 시작됩니다.
새 게임을 받고 게임 세션에 들어가면 매번 클라이언트가 응답할 때까지 기다려야 하며 프로세스가 차단됩니다.
게임이 끝나면 네트워크 서버 프로세스는 클라이언트가 다시 플레이를 원하는지 확인합니다(라이브 연결에 해당). 연결이 닫히면(클라이언트가 나가거나 시간 초과되면) 네트워크 서버 프로세스는 새 게임을 수신 대기하는 상태로 돌아갑니다.
각 활성 HTTP 연결, 즉 각 체스 게임에 참여하려면 체스 마스터와 같은 특정 프로세스나 스레드가 필요하다는 점을 기억하세요. 이 아키텍처는 타사 모델이나 새로운 규칙을 간단하고 쉽게 확장할 수 있습니다. 그러나 여기에는 매우 불균형한 논리가 있습니다. 단일 파일 설명자와 적은 양의 메모리로 표시되는 경량 HTTP 연결의 경우 이 연결은 스레드 또는 프로세스에 매핑되며 스레드 또는 프로세스는 가중치 수준입니다. 운영 체제 개체. 프로그래밍할 때는 편리하지만 낭비가 엄청납니다.
NGINX는 진짜 달인입니다
어쩌면 당신이 나 체스 마스터가 12명의 플레이어와 동시에 플레이하는 게임이 동시에 상영된다는 이야기를 들었습니다.
NGINX 작업자 프로세스도 이렇게 "체스"를 합니다. 각 작업자 프로세스 - 하나의 A CPU 코어 작업자 - 수천 개의 게임을 동시에 처리할 수 있는 마스터입니다.
작업자 프로세스가 연결되어 소켓에서 수신 대기를 시작합니다.
소켓이 이벤트를 수신하면 작업자 프로세스가 즉시 이벤트를 처리합니다.
작업자 프로세스는 상대(클라이언트)의 응답을 기다리면서 네트워크 전송을 차단하지 않습니다. 이동할 때마다 작업자 프로세스는 대기 중인 다른 체스 게임을 빠르게 처리하거나 새 플레이어를 환영합니다.
차단 다중 프로세스 프레임워크보다 빠른 이유는 무엇인가요?
NGINX의 뛰어난 확장성은 수천 개의 연결을 처리하기 위해 하나의 작업자 스레드를 지원한다는 것입니다. 각각의 새로운 연결은 파일 설명자를 생성하여 작업자 프로세스의 추가 메모리 중 극히 일부만 소비하며 추가 오버헤드도 매우 적습니다. 프로세스는 항상 CPU에 고정될 수 있으므로 컨텍스트 전환은 상대적으로 드물고 작업이 없을 때만 발생합니다. 역자 주: CPU 바인딩은 하나 이상의 프로세스를 하나 이상의 프로세서에 바인딩하는 것을 의미합니다.
블로킹 방식을 사용합니다. 즉, 하나의 연결에 해당합니다. 하나의 프로세스에서 각 연결에는 많은 추가 리소스와 오버헤드가 필요하며 컨텍스트 전환이 매우 자주 발생합니다.
(자세한 내용은 NGINX 아키텍처에 대한 Andrew Alexeev의 기사를 참조하세요. 저자는 NGINX 공동 창립자이자 기업 개발 담당 부사장입니다.)
시스템이 적절하게 조정되는 한 NGINX의 각 작업자 프로세스는 수천 개의 동시 HTTP 연결을 처리하고 네트워크 피크에 문제 없이 대처할 수 있습니다. 즉, 동시에 더 많은 체스 게임을 플레이할 수 있습니다. 시간.
NGINX를 업그레이드하기 위해 구성 파일 업데이트
프로세스 프레임워크에는 소수의 작업자 프로세스가 있어 구성이 용이합니다. 파일 및 바이너리 파일 업데이트까지 가능합니다.
NGINX 구성 업데이트는 간단하고 가볍고 안정적인 작업입니다. 즉, nginx -s reload 명령을 실행하는 동안 디스크의 구성 파일을 확인하고 SIGHUB 신호가 기본 프로세스로 전송됩니다.
메인 프로세스가 SIGHUB를 수신하면 다음 두 가지 작업을 수행합니다.
구성 파일을 다시 로드하고 새로운 작업자 프로세스 집합을 생성하면 새로 생성된 작업자 프로세스가 즉시 연결을 수락하고 네트워크 통신을 처리합니다(새 구성 환경 채택).
이전 작업자 프로세스가 정상적으로 출시되고 해당 작업자 프로세스가 새 연결 수락을 중지하도록 알립니다. 현재 처리 중인 HTTP 요청이 끝나면 작업자 프로세스는 연결을 닫습니다. 모든 연결이 닫히면 작업자 프로세스가 종료됩니다.
프로세스를 다시 로드하면 약간의 CPU 및 메모리 스파이크가 발생하지만 활성 연결에서 리소스를 로드하는 것에 비해 오버헤드가 최소화됩니다. 구성 파일은 초당 여러 번 다시 로드될 수 있습니다. 종료 대기 중인 연결을 많이 생성하는 NGINX 작업자 프로세스는 일반적으로 문제를 일으키는 경우가 거의 없지만 문제가 있더라도 신속하게 해결할 수 있습니다.
NGINX 바이너리 파일 업그레이드는 탁월한 고가용성을 제공합니다. 연결 손실, 서비스 중단 시간 또는 중단 없이 온라인으로 파일을 업그레이드할 수 있습니다. 번역자 주: 즉석에서 프로그램이 실행되는 동안 작업이 완료될 수 있습니다.
바이너리 파일 업그레이드 프로세스는 우아한 구성 파일 다시 로드와 유사합니다. 새로운 NGINX 메인 프로세스는 원래 메인 프로세스와 병렬로 실행되며 청취 소켓을 공유합니다. 두 프로세스 모두 활성화되어 해당 네트워크 통신을 처리합니다. 원래 기본 프로세스와 해당 작업자 프로세스가 정상적으로 종료되도록 알릴 수 있습니다.
자세한 과정 설명은 NGINX Control 참조
최종 결론
NGINX 내부 인포그래픽은 NGINX의 수준 높은 기능 파노라마를 보여줍니다. 간단한 설명 뒤에는 10년 이상 지속적인 혁신과 최적화가 담겨 있습니다. 다양한 하드웨어 플랫폼에 적용되어 최고의 성능을 달성했습니다. 현대에도 네트워크 애플리케이션은 보안과 안정성을 유지해야 하며 NGINX는 탁월한 성능을 발휘합니다.
NGINX 최적화에 대해 더 알고 싶다면 다음의 좋은 정보를 참조하세요.
NGINX 설치 및 성능 튜닝
NGINX 성능 튜닝
《Nginx, 스레드 풀 도입해 성능 9배 향상》
NGINX - 오픈 소스 애플리케이션 프레임워크
NGINX 소켓 분할(소켓 샤딩) 릴리스 버전 1.9.1
재인쇄 출처: Python 개발자
위 내용은 Nginx가 성능과 규모를 고려하여 어떻게 설계되었는지 소개합니다. , 관련 내용을 포함하여 PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.
