Nginx는 요청 처리를 여러 단계로 나눕니다. 이 단계에서 IO 차단이 발생합니까? Blocking이 있으면 Nginx는 다른 요청을 실행하는데, 다른 요청을 실행할 때 우선순위 구분이 있나요(이미 다음 단계로 진행된 요청이 먼저 실행되나요?) 또한 Nginx는 각 단계에서 처리할 수 있는 스레드 풀을 갖게 됩니까, 아니면 처음부터 끝까지 자체 스레드를 갖게 됩니까?
cat /proc/3776/status|grep Threads Nginx 작업자 프로세스에는 스레드가 1개만 있고 그 중 3776이 Nginx 작업자 프로세스의 PID임을 알 수 있습니다. 또한 Nginx는 1.7.11부터 AIO 스레드 풀 지원을 추가했으며 AIO 멀티스레딩을 사용하여 대용량 파일을 읽고 보낼 수 있어 작업자 프로세스가 차단되는 것을 방지할 수 있습니다(작은 파일에는 sendfile을 사용하고 대용량 파일에는 AIO 스레드 풀을 사용) ) 스레드 풀 지원을 활성화하려면 구성 시 --with-threads 옵션을 명시적으로 추가해야 합니다. https://www.nginx.com/blog/thread-pools-boost-performance-9x/ http://nginx.org/en/docs/ngx_core_module.html#thread_pool
전송: listen_fd에 새로운 accept() 요청이 있으면 운영 체제는 모든 하위 프로세스를 깨웁니다. 왜냐하면 이러한 프로세스는 모두 epoll_wait()가 동일한 listening_fd이고 운영 체제는 누가 수락을 담당하는지 판단할 방법이 없기 때문입니다. 그래서 단순히 모두 깨우지만 결국 하나의 프로세스만 성공적으로 수락하고 다른 프로세스는 수락에 실패하게 됩니다. 따라서 이를 Thundering Herd라고 합니다.
수신 소켓은 시작 시 초기화됩니다. 작업자 프로세스는 이러한 소켓을 통해 요청을 수락하고 읽고 응답을 출력합니다. Nginx는 PHP-FPM과 같은 요청을 배포하기 위해 마스터 프로세스를 사용하지 않습니다. , 따라서 패닉 현상이 발생할 수 있습니다. 즉, listening_fd에 새로운 accept() 요청이 있으면 운영 체제가 모든 하위 프로세스를 깨울 것입니다.
천둥 그룹 해결에 대한 Nginx의 아이디어: 천둥 그룹을 피하세요. http://nginx.org/en/docs/ngx_core_module.html#accept_mutex 구체적인 조치에는 전역 뮤텍스 잠금(accept_mutex on) 사용이 포함되며, 각 잠금을 적용하기 전에 epoll_wait()의 작업자 프로세스에서 응용 프로그램을 얻으면 처리를 계속하고, 얻지 못하면 대기하며 로드 밸런싱 알고리즘을 설정합니다(특정 작업 프로세스의 작업량이 7/8에 도달한 경우). 각 프로세스의 작업량 균형을 맞추기 위해 다시 잠금을 적용하려고 시도하지 않습니다.
천둥 떼를 해결하는 Nginx의 새로운 방법: 커널에서 제공하는 Socket ReusePort 기능을 사용합니다. NGINX 1.9.1은 소켓 샤딩을 지원합니다. http://nglua.com/docs/sharding.html NGINX1.9.1은 다음의 SO_REUSEPORT 옵션을 지원합니다. 소켓, 이 옵션은 DragonFly BSD 및 Linux(3.9+ 커널)를 포함한 많은 운영 체제의 최신 버전에서 사용할 수 있습니다. 이 옵션을 사용하면 여러 소켓이 동일한 IP 주소 및 포트 조합을 수신할 수 있습니다. 효과적인 조각화. SO_REUSEPORT 옵션이 켜져 있지 않으면 연결이 들어올 때 수신 소켓이 기본적으로 프로세스에 알립니다. 이때 accept_mutex off 명령이 모든 작업자 프로세스를 깨우면 이를 얻기 위해 경쟁하게 됩니다. 이를 Thundering Herd 현상이라고 합니다. 잠금을 설정하지 않고(accept_mutex off) epoll을 사용하면 Listening 포트에 읽기 작업이 있을 때 SO_REUSEPORT 옵션을 활성화한 후에는 Thundering Herd 현상이 발생합니다. 커널은 연결을 얻기 위한 유효한 소켓(프로세스)이 무엇인지 결정합니다. 이는 대기 시간을 줄이고 작업자 프로세스의 성능을 향상시키며, 이는 작업자 프로세스가 처리할 준비가 되기 전에 새로운 연결이 제공된다는 의미이기도 합니다.
nginx는 기본적으로 하나의 마스터 프로세스와 여러 작업자 프로세스로 구성된 다중 프로세스 모드에서 작동합니다. 마스터 프로세스는 주로 작업자 프로세스를 관리하는 데 사용됩니다. 여러 작업자 프로세스가 클라이언트의 요청을 동등하게 처리할 수 있습니다. 그러나 다른 작업자 프로세스의 요청은 처리할 수 없습니다. 각 작업자 프로세스에는 하나의 기본 스레드만 있습니다. epoll은 비동기 비차단 방법을 사용하여 요청을 처리하여 여러 이벤트를 모니터링합니다(소켓 폴링). ) 이벤트가 준비되지 않은 경우 epoll에 넣습니다. 이벤트가 준비되면 읽고 씁니다. 멀티스레딩에 비해 이 이벤트 처리 방법은 스레드를 만들 필요가 없으며 각 요청을 차지합니다. 또한 메모리가 매우 적고 컨텍스트 전환이 없으며 이벤트 처리가 매우 가볍습니다. 동시성이 아무리 많아도 불필요한 리소스 낭비(컨텍스트 전환)가 발생하지 않습니다. httpd의 일반적인 작업 방법은 각 요청이 작업 스레드를 점유한다는 것입니다. 동시성 수가 수천 개에 도달하면 동시에 요청을 처리하는 스레드가 수천 개 있게 됩니다. 이는 운영 체제에 대한 메모리 사용량입니다. 이로 인해 발생하는 연결 수는 매우 크고 스레드 컨텍스트 전환으로 인한 CPU 오버헤드도 매우 큽니다. 당연히 httpd의 성능은 향상될 수 없습니다. Tengine 팀은 이전에 Nginx가 처리하는 연결 수를 테스트했습니다. 동시 요청 수는 200만 개 이상에 도달했습니다. (평균 1G 메모리는 80,000개 이상의 요청을 처리할 수 있습니다.) Nginx는 특정 프로세스를 특정 코어에 바인딩(CPU Affinity Binding)하는 기능을 지원하므로 이로 인해 문제가 발생하지 않습니다. 캐시 오류를 방지하려면 CPU의 코어 수에 따라 여러 작업자 프로세스를 설정하는 것이 좋습니다. 그러나 작업자 프로세스가 너무 많으면 프로세스가 CPU 리소스를 놓고 경쟁하게 되어 불필요한 컨텍스트가 발생한다는 점에 유의하세요. 따라서 작업자 프로세스는 프로세스가 많을수록 좋습니다. 자세한 내용은 http://tengine.taobao.org/book/chapter_02.html
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
cat /proc/3776/status|grep ThreadsNginx 작업자 프로세스에는 스레드가 1개만 있고 그 중 3776이 Nginx 작업자 프로세스의 PID임을 알 수 있습니다. 또한 Nginx는 1.7.11부터 AIO 스레드 풀 지원을 추가했으며 AIO 멀티스레딩을 사용하여 대용량 파일을 읽고 보낼 수 있어 작업자 프로세스가 차단되는 것을 방지할 수 있습니다(작은 파일에는 sendfile을 사용하고 대용량 파일에는 AIO 스레드 풀을 사용) ) 스레드 풀 지원을 활성화하려면 구성 시 --with-threads 옵션을 명시적으로 추가해야 합니다.https://www.nginx.com/blog/thread-pools-boost-performance-9x/
http://nginx.org/en/docs/ngx_core_module.html#thread_pool
전송:
listen_fd에 새로운 accept() 요청이 있으면 운영 체제는 모든 하위 프로세스를 깨웁니다. 왜냐하면 이러한 프로세스는 모두 epoll_wait()가 동일한 listening_fd이고 운영 체제는 누가 수락을 담당하는지 판단할 방법이 없기 때문입니다. 그래서 단순히 모두 깨우지만 결국 하나의 프로세스만 성공적으로 수락하고 다른 프로세스는 수락에 실패하게 됩니다. 따라서 이를 Thundering Herd라고 합니다.
수신 소켓은 시작 시 초기화됩니다. 작업자 프로세스는 이러한 소켓을 통해 요청을 수락하고 읽고 응답을 출력합니다. Nginx는 PHP-FPM과 같은 요청을 배포하기 위해 마스터 프로세스를 사용하지 않습니다. , 따라서 패닉 현상이 발생할 수 있습니다. 즉, listening_fd에 새로운 accept() 요청이 있으면 운영 체제가 모든 하위 프로세스를 깨울 것입니다.
천둥 그룹 해결에 대한 Nginx의 아이디어: 천둥 그룹을 피하세요.
http://nginx.org/en/docs/ngx_core_module.html#accept_mutex
구체적인 조치에는 전역 뮤텍스 잠금(accept_mutex on) 사용이 포함되며, 각 잠금을 적용하기 전에 epoll_wait()의 작업자 프로세스에서 응용 프로그램을 얻으면 처리를 계속하고, 얻지 못하면 대기하며 로드 밸런싱 알고리즘을 설정합니다(특정 작업 프로세스의 작업량이 7/8에 도달한 경우). 각 프로세스의 작업량 균형을 맞추기 위해 다시 잠금을 적용하려고 시도하지 않습니다.
천둥 떼를 해결하는 Nginx의 새로운 방법: 커널에서 제공하는 Socket ReusePort 기능을 사용합니다.
NGINX 1.9.1은 소켓 샤딩을 지원합니다.
http://nglua.com/docs/sharding.html
NGINX1.9.1은 다음의 SO_REUSEPORT 옵션을 지원합니다. 소켓, 이 옵션은 DragonFly BSD 및 Linux(3.9+ 커널)를 포함한 많은 운영 체제의 최신 버전에서 사용할 수 있습니다. 이 옵션을 사용하면 여러 소켓이 동일한 IP 주소 및 포트 조합을 수신할 수 있습니다. 효과적인 조각화. SO_REUSEPORT 옵션이 켜져 있지 않으면 연결이 들어올 때 수신 소켓이 기본적으로 프로세스에 알립니다. 이때 accept_mutex off 명령이 모든 작업자 프로세스를 깨우면 이를 얻기 위해 경쟁하게 됩니다. 이를 Thundering Herd 현상이라고 합니다. 잠금을 설정하지 않고(accept_mutex off) epoll을 사용하면 Listening 포트에 읽기 작업이 있을 때 SO_REUSEPORT 옵션을 활성화한 후에는 Thundering Herd 현상이 발생합니다. 커널은 연결을 얻기 위한 유효한 소켓(프로세스)이 무엇인지 결정합니다. 이는 대기 시간을 줄이고 작업자 프로세스의 성능을 향상시키며, 이는 작업자 프로세스가 처리할 준비가 되기 전에 새로운 연결이 제공된다는 의미이기도 합니다.
nginx는 기본적으로 하나의 마스터 프로세스와 여러 작업자 프로세스로 구성된 다중 프로세스 모드에서 작동합니다. 마스터 프로세스는 주로 작업자 프로세스를 관리하는 데 사용됩니다. 여러 작업자 프로세스가 클라이언트의 요청을 동등하게 처리할 수 있습니다. 그러나 다른 작업자 프로세스의 요청은 처리할 수 없습니다. 각 작업자 프로세스에는 하나의 기본 스레드만 있습니다. epoll은 비동기 비차단 방법을 사용하여 요청을 처리하여 여러 이벤트를 모니터링합니다(소켓 폴링). ) 이벤트가 준비되지 않은 경우 epoll에 넣습니다. 이벤트가 준비되면 읽고 씁니다. 멀티스레딩에 비해 이 이벤트 처리 방법은 스레드를 만들 필요가 없으며 각 요청을 차지합니다. 또한 메모리가 매우 적고 컨텍스트 전환이 없으며 이벤트 처리가 매우 가볍습니다. 동시성이 아무리 많아도 불필요한 리소스 낭비(컨텍스트 전환)가 발생하지 않습니다. httpd의 일반적인 작업 방법은 각 요청이 작업 스레드를 점유한다는 것입니다. 동시성 수가 수천 개에 도달하면 동시에 요청을 처리하는 스레드가 수천 개 있게 됩니다. 이는 운영 체제에 대한 메모리 사용량입니다. 이로 인해 발생하는 연결 수는 매우 크고 스레드 컨텍스트 전환으로 인한 CPU 오버헤드도 매우 큽니다. 당연히 httpd의 성능은 향상될 수 없습니다. Tengine 팀은 이전에 Nginx가 처리하는 연결 수를 테스트했습니다. 동시 요청 수는 200만 개 이상에 도달했습니다. (평균 1G 메모리는 80,000개 이상의 요청을 처리할 수 있습니다.) Nginx는 특정 프로세스를 특정 코어에 바인딩(CPU Affinity Binding)하는 기능을 지원하므로 이로 인해 문제가 발생하지 않습니다. 캐시 오류를 방지하려면 CPU의 코어 수에 따라 여러 작업자 프로세스를 설정하는 것이 좋습니다. 그러나 작업자 프로세스가 너무 많으면 프로세스가 CPU 리소스를 놓고 경쟁하게 되어 불필요한 컨텍스트가 발생한다는 점에 유의하세요. 따라서 작업자 프로세스는 프로세스가 많을수록 좋습니다. 자세한 내용은
을 참조하세요.http://tengine.taobao.org/book/chapter_02.html