Nginx는 worker_connections"작업자 프로세스가 열 수있는 최대 동시 연결 수를 설정합니다.이 숫자에는 클라이언트와의 연결뿐만 아니라 모든 연결 (예 : 프록시 서버와의 연결)이 포함됩니다. 또 다른 고려 사항은 실제 동시 연결 수입니다. 최대 열린 파일 수에 대한 현재 제한을 초과 할 수 없습니다. " 이 문제에 대한 몇 가지 쿼리가 있습니다.
답변:
실용적인 접근을하겠습니다.
이러한 모든 한계는 하드웨어가 느리고 비용이 많이 드는 지난 세기에 하드 코딩되어 설계되었습니다. 2016 년 현재 월마트 토스터는 평균보다 더 많은 요청을 처리 할 수 있습니다.
기본 설정은 실제로 위험합니다. 웹 사이트에 수백 명의 사용자가 있다는 것은 인상적인 것이 아닙니다.
관련 설정에 대해 설명하면서 설명하겠습니다.
로드 밸런서로서의 nginx :
웹 서버로서의 nginx :
이것은 까다 롭습니다.
일부 응용 프로그램 / 프레임 워크 / 미들웨어 (예 : php-fpm)는 nginx 외부에서 실행됩니다. 이 경우, 1 개의 nginx 작업자는 일반적으로 많은 처리를 수행하고 자원을 먹는 외부 응용 프로그램이므로 충분합니다.
또한 일부 응용 프로그램 / 프레임 워크 / 미들웨어는 한 번에 하나의 요청 만 처리 할 수 있으며 과부하가 발생합니다.
일반적으로, 1 명의 작업자는 항상 안전한 내기입니다.
그렇지 않으면 자신이하는 일을 알고 있다면 코어 당 한 명의 작업자를 배치 할 수 있습니다. 그 경로를 최적화로 고려하고 적절한 벤치마킹 및 테스트를 조언합니다.
총 연결 량은입니다 worker_process * worker_connections. 로드 밸런서 모드에서 절반입니다.
이제 토스터 부분에 도달했습니다. 심각하게 과소 평가 된 시스템 한계가 많이 있습니다.
안전한 기본값은 1k를 어디에나 두는 것입니다.
내부 및 알려지지 않은 대부분의 사이트보다 훨씬 높을 수 있습니다. 다른 시스템 한계에 도달하지 않을 정도로 낮습니다.
특히 공개 웹 사이트의 경우 수천 명의 클라이언트가있는 것이 매우 일반적입니다. 나는 기본값이 낮아서 다운 된 웹 사이트의 수를 세는 것을 중단했습니다.
생산에 허용되는 최소값은 10k입니다. 허용하려면 관련 시스템 제한을 늘려야합니다.
너무 높은 한도는 없습니다 (사용자가없는 한도는 아무런 영향을 미치지 않습니다). 그러나 제한이 너무 낮 으면 사용자가 거부되고 사이트가 손상되는 매우 실제적인 것입니다.
10k는 훌륭하고 쉽습니다.
우리는 임의의 1000kk 제한을 설정할 수는 있지만 (실제로는 한계 일뿐), 실제로는 그다지 의미가 없으며, 트래픽을 얻지 못하고 어쨌든 취할 수 없습니다.
합리적인 설정으로 10k를 고수합시다. 더 많은 서비스를 원하고 실제로 할 수있는 서비스에는 특별한 조정 및 벤치마킹이 필요합니다.
때때로 우리는 서버에 많은 리소스가 없다는 것을 알고 있으며 우리가 할 수없는 스파이크를 기대합니다. 시도하는 것보다 사용자를 거부하는 것이 좋습니다. 이 경우 적절한 연결 제한을 설정하고 멋진 오류 메시지 및 처리를 구성하십시오.
때로는 백엔드 서버가 제대로 작동하지만 최대 부하 까지만 걸리고 더 많은 것이 남게됩니다. 서버가 충돌하는 것보다 속도가 느려집니다. 이 경우 엄격한 제한으로 대기열을 구성하고 요청이 제한 속도로 배수되는 동안 nginx가 모든 열을 버퍼링하도록하십시오.
sendfile우리가 곱할 수 있도록 하나의 연결에 필요한 RAM의 양 (예 : 일반 정적 파일 저장)을 대략 알아야 할 것 같습니다. 주어진 수의를 유지하는 데 필요한 RAM의 양을 계산하십시오 worker_connections.
sysctl설정됩니다.
ulimit -a 시스템에서 프로세스가 사용할 수있는 열린 파일 수를 알려줍니다.
또한 net.ipv4.ip_local_port_rangeIP 당 활성화 할 총 소켓 범위를 설정합니다.
따라서 TCP 대기열의 전체 크기 worker_connections까지 클라이언트 연결이 그 이상이어야합니다 net.core.netdev_max_backlog.
nginx를 리버스 프록시로 사용하는 경우 연결 당 두 개의 소켓을 사용합니다. net.ipv4.tcp_fin_timeout소켓 상태를 빠르게 전환하기 위해 약간의 커널 tcp 관련 시간 초과를 사용 하고 싶을 수도 있습니다 . 주목해야 할 또 다른 사항은 각 소켓이 TCP 메모리 스택의 메모리를 할당한다는 것입니다. 또한를 사용하여 TCP 메모리 스택의 일부 제한을 설정할 sysctl수 있습니다 .CPU와 충분한 파일 처리기가있는 한 RAM에 더 많은 압력을 가할 수 있습니다.
참고로 충분한 컴퓨팅 리소스가 주어지면 약 32GB 램을 가진 하나의 서버와 sysctl을 사용하여 일부 커널 조정으로 1MM 동시 연결을 처리하기위한 일부 가상 네트워크 인터페이스를 가질 수 있습니다. 1MM 이상을 처리하고 약 700Bytes의 페이로드를 보낼 때 테스트하는 동안 서버는 약 1.2MM 동시 클라이언트를 업데이트하는 데 약 10 초가 걸렸습니다. 다음으로 여분의 NIC를 결합하고 가상 닉스를 버림으로써 네트워크 대역폭을 늘리는 것이 었습니다. 페이로드, 대역폭 및 모든 클라이언트를 업데이트 할 수있는 적절한 시간이 주어지면 1.2MM 이상의 클라이언트와 의사 근처에서 실시간으로 의사 소통 할 수 있습니다.
행복한 튜닝!
Nginx가 처리하는 트래픽 유형에 따라 가변적이므로 테스트를 통해 적절한 사이징을 발견 할 수 있습니다.
이론적으로 nginx는 다음을 처리 할 수 있습니다. 최대 클라이언트 = worker_processes * worker_connections (* = 곱하기) 및 worker_processes = 프로세서 수
프로세서를 찾으려면 다음을 사용하십시오. grep processor / proc / cpuinfo | 화장실 -l
리소스 제한이있을 때 하한값을 설정하면 유용 할 수 있습니다. 예를 들어 연결 유지 연결과 같은 일부 연결 (클라이언트뿐만 아니라 업스트림 서버 와도 연결)은 리소스를 효과적으로 낭비하고 있으며 (nginx가 매우 효율적이거나 효율적인 경우에도) 필요하지 않습니다. 범용 서버의 올바른 작동, 나머지 작업에 더 많은 리소스를 사용할 수 있도록 안전하게 제거 할 수 있음을 의미합니다.
따라서 자원 제한이 낮 으면 nginx에 물리적 자원이 부족할 수 있으며 사용 가능한 자원이 새 연결에 할당되지 않고 새 연결에 할당하는 대신 새로운 연결에 할당되어야 함을 나타냅니다. 더 시급한 요구에 부응하십시오.
권장 값은 무엇입니까? 기본값입니다.
기본값은 모두 문서 내에 문서화되어 있습니다.
기본값 : worker_connections 512;
그리고 수 의 소스 코드 수준에서 확인event/ngx_event.c 도
13 # DEFAULT_CONNECTIONS 512 정의
Marcel의 답변은 실제로 상향 조정되어야합니다! ulimits가 기본값 약 1k로 설정되면 max_connections는 같은 값으로 설정해야합니다. 그렇지 않으면 max_connections를 10k로 설정하면 이점이 없습니다.
"worker_connections는 그보다 많거나 net.core.netdev_max_backlog-TCP 큐의 전체 크기가 될 때까지 클라이언트 연결이 대기열에있을 때"대기중인 요청 및 소켓을 nginx에서 닫습니다.
ulimits가 허용하는 한 연결에 따라 단일 프로세스가 열릴 수 있습니다. num_workers * max_connections는 공식이지만 외부로드 밸런서 / 프록시 최대 연결이며 ulimits는 합리적인 값을 고려해야합니다. ulimits가 제한 요소이므로 max_connection을 실제로 높은 값으로 설정하면 역효과가 발생할 수 있습니다.
max_connections기본 소프트 제한보다 높은 경우 ulimit를 자동으로 증가시킵니다 .