Nginx 서버 고성능 최적화 설정 방법 소결

일반적으로 최적화 된 Nginx Linux 서버 는 500, 000 ㎡ C 600, 000 회 / 초의 요청 처리 성능 에 도달 할 수 있 지만 나의 Nginx 서버 는 904, 000 회 / 초의 처리 성능 에 안정 적 으로 도달 할 수 있 고 나 는 이 고부 하 테스트 를 통 해 12 시간 을 초과 하여 서버 작업 이 안정 적 이다.
여기 서 특별히 설명해 야 할 것 은 본 논문 에 열 거 된 모든 설정 은 나의 테스트 환경 에서 검 증 된 것 이 고 서버 의 상황 에 따라 설정 해 야 한 다 는 것 이다.
EPEL 소스 에서 Nginx 설치 하기:

yum -y install nginx

프로필 을 백업 하고 필요 에 따라 설정 합 니 다:

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
  vim /etc/nginx/nginx.conf

# This number should be, at maximum, the number of CPU cores on your system.
# (since nginx doesn't benefit from more than one worker per CPU.)
#           CPU     ，            1   Nginx                。
worker_processes 24;
 
# Number of file descriptors used for Nginx. This is set in the OS with 'ulimit -n 200000'
# or using /etc/security/limits.conf
# Nginx            ，            "ulimit -n 200000"，    /etc/security/limits.conf    。 
worker_rlimit_nofile 200000;
 
# only log critical errors
#     critical        
error_log /var/log/nginx/error.log crit
 
# Determines how many clients will be served by each worker process.
# (Max clients = worker_connections * worker_processes)
# "Max clients" is also limited by the number of socket connections available on the system (~64k)
#      Nginx              ，（        =        *     ）
#                socket       （   64K ）
worker_connections 4000;
 
# essential for linux, optmized to serve many clients with each thread
# Linux     ，               。
use epoll;
 
# Accept as many connections as possible, after nginx gets notification about a new connection.
# May flood worker_connections, if that option is set too low.
#               ，   worker_connections     ，            。
multi_accept on;
 
# Caches information about open FDs, freqently accessed files.
# Changing this setting, in my environment, brought performance up from 560k req/sec, to 904k req/sec.
# I recommend using some varient of these options, though not the specific values listed below.
#          FDs（     /    ）
#         ，        ，    560k   /      904k   / 。
#                 ，            。
open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
 
# Buffer log writes to speed up IO, or disable them altogether
#         IO     ，        。
# access_log /var/log/nginx/access.log main buffer=16k;
access_log off;
 
# Sendfile copies data between one FD and other from within the kernel.
# More efficient than read() + write(), since the requires transferring data to and from the user space.
#    sendfile   ，      FD       ，         read() + write()        。
sendfile on;
 
# Tcp_nopush causes nginx to attempt to send its HTTP response head in one packet,
# instead of using partial frames. This is useful for prepending headers before calling sendfile,
# or for throughput optimization.
#    tcp_nopush   ，Nginux     HTTP                   。
#           sendfile         HTTP   ，           。
tcp_nopush on;
 
# don't buffer data-sends (disable Nagle algorithm). Good for sending frequent small bursts of data in real time.
#      data-sends （   Nagle   ），                   。
tcp_nodelay on;
 
# Timeout for keep-alive connections. Server will close connections after this time.
#      keep-alive     ，                。
keepalive_timeout 30;
 
# Number of requests a client can make over the keep-alive connection. This is set high for testing.
#        keep-alive             ，      ，          。
keepalive_requests 100000;
 
# allow the server to close the connection after a client stops responding. Frees up socket-associated memory.
#                      ，          socket     。
reset_timedout_connection on;
 
# send the client a "request timed out" if the body is not loaded by this time. Default 60.
#              ，    60  。
client_body_timeout 10;
 
# If the client stops reading data, free up the stale client connection after this much time. Default 60.
#           ，         ，           ，    60  。
send_timeout 2;
 
# Compression. Reduces the amount of data that needs to be transferred over the network
#       ，             。
gzip on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
gzip_disable "MSIE [1-6].";

Nginx 를 시작 하고 자동 로드 를 설정 합 니 다.

service nginx start
  chkconfig nginx on

Tsung 을 설정 하고 테스트 를 시작 합 니 다. 테스트 가 10 분 정도 차이 나 지 않 으 면 서버 의 피크 능력 을 테스트 할 수 있 습 니 다. 구체 적 인 시간 은 Tsung 설정 과 관련 이 있 습 니 다.

[root@loadnode1 ~] vim ~/.tsung/tsung.xml

tsung start

테스트 결과 가 충분 하 다 고 생각 되 는 경우 ctrl + c 를 통 해 종료 한 후, 우리 가 설정 한 별명 명령 treport 를 사용 하여 테스트 보고 서 를 봅 니 다.
WEB 서버 조정, 두 번 째 부분: TCP 프로 토 콜 창고 조정
이 부분 은 Ngiinx 에 만 적용 되 는 것 이 아니 라 모든 WEB 서버 에서 도 사용 할 수 있다.커 널 TCP 설정 에 대한 최적화 로 서버 네트워크 대역 폭 을 높 일 수 있 습 니 다.
아래 설정 은 제 10 - Gbase - T 서버 에서 완벽 하 게 작 동 되 었 습 니 다. 서버 는 기본 설정 의 8Gbps 대역 폭 에서 9.3Gbps 로 향상 되 었 습 니 다.
물론 서버 의 결론 은 다 를 수 있 습 니 다.
다음 설정 항목 은 매번 한 가지 만 수정 한 다음 네트워크 성능 테스트 도구 netperf, iperf 또는 유사 한 테스트 스 크 립 트 cluster - netbench. pl 로 서버 를 여러 번 테스트 하 는 것 을 권장 합 니 다.

yum -y install netperf iperf
vim /etc/sysctl.conf

# Increase system IP port limits to allow for more connections
#       IP         ，          
net.ipv4.ip_local_port_range = 2000 65000
 
net.ipv4.tcp_window_scaling = 1
 
# number of packets to keep in backlog before the kernel starts dropping them
#                ，             
net.ipv4.tcp_max_syn_backlog = 3240000
 
# increase socket listen backlog
#    socket      
net.core.somaxconn = 3240000
net.ipv4.tcp_max_tw_buckets = 1440000
 
# Increase TCP buffer sizes
#    TCP     
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_congestion_control = cubic

설정 을 수정 할 때마다 다음 명령 을 실행 해 야 합 니 다.

sysctl -p /etc/sysctl.conf

설정 수정 후 반드시 네트워크 벤 치 마크 테스트 를 해 야 한 다 는 것 을 잊 지 마 세 요. 그러면 구체 적 으로 어떤 설정 수정의 최적화 효과 가 가장 뚜렷 한 지 관찰 할 수 있 습 니 다.이런 효과 적 인 테스트 방법 을 통 해 너 를 위해 많은 시간 을 절약 할 수 있다.
일반 최적화 설정 항목
일반적으로 nginx 프로필 에서 최적화 에 효과 가 있 는 것 은 다음 과 같은 몇 가지 입 니 다. 1. workerprocesses 8; nginx 프로 세 스 수 는 cpu 수 에 따라 지정 하 는 것 을 권장 합 니 다. 일반적으로 2 개의 4 핵 cpu 는 8 입 니 다.2. worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; 프로 세 스 마다 cpu 를 할당 합 니 다. 8 개의 프로 세 스 를 8 개의 cpu 에 할당 합 니 다. 물론 여러 개 를 쓰 거나 하나의 프로 세 스 를 여러 cpu 에 할당 할 수 있 습 니 다.3. worker_rlimit_nofile 65535; 이 명령 은 nginx 프로 세 스 가 열 린 가장 많은 파일 설명자 수 를 말 합 니 다. 이론 적 값 은 최대 열 린 파일 수 (ulimit - n) 와 nginx 프로 세 스 수 를 제외 해 야 합 니 다. 그러나 nginx 배분 요청 이 고 르 지 않 기 때문에 ulimit - n 의 값 과 일치 하 는 것 이 좋 습 니 다.현재 Liux 2.6 커 널 에서 파일 열기 수 는 65535, worker 입 니 다.rlimit_nofile 은 상응 하여 65535 를 작성 해 야 합 니 다.
이 는 nginx 가 스케줄 링 할 때 프로 세 스 에 요청 하 는 것 이 균형 이 맞지 않 기 때문에 10240 을 작성 하면 총 병발 량 이 3 - 4 만 에 이 르 면 프로 세 스 가 10240 을 초과 할 수 있 습 니 다. 이 때 502 오 류 를 되 돌려 줍 니 다.링크 ux 시스템 파일 설명 자 를 보 는 방법:

[root@web001 ~]# sysctl -a | grep fs.file

fs.file-max = 789972
fs.file-nr = 510 0 789972

4. use epoll; epoll 의 I / O 모델 사용 하기(추가 설명: apache 와 유사 하여 nginx 는 서로 다른 운영 체제 에 대해 서로 다른 이벤트 모델 A) 표준 이벤트 모델 Select, poll 은 표준 이벤트 모델 에 속 합 니 다. 현재 시스템 에 더 효과 적 인 방법 이 존재 하지 않 으 면 nginx 는 select 또는 poll B) 고 효율 이벤트 모델 Kqueue 를 선택 합 니 다. FreeBSD 4.1 +, OpenBSD 2.9 +, NetBSD 2.0 과 MacOS X 에 사 용 됩 니 다. 더 블 프로 세 서 를 사용 하 는MacOS X 시스템 은 kqueue 를 사용 하면 커 널 붕 괴 를 초래 할 수 있 습 니 다. Epol: Linux 커 널 2.6 버 전 및 이후 시스템 에 사 용 됩 니 다.
/ dev / poll: Solaris 7 11 / 99 +, HP / UX 11.22 + (eventport), IRIX 6.5.15 + 와 Tru 64 UNIX 5.1A + 에 사 용 됩 니 다. Eventport: Solaris 10 에 사 용 됩 니 다. 커 널 붕괴 문 제 를 방지 하기 위해 보안 패 치 를 설치 할 필요 가 있 습 니 다.)5. worker connections 65535; 모든 프로 세 스 가 허용 하 는 최대 연결 수, 이론 적 으로 모든 nginx 서버 의 최대 연결 수 는 worker processes * worker connections 입 니 다. 6. keepalive timeout 60; keepalive 시간 초과. 7. client header buffer size 4k; 클 라 이언 트 는 머리의 버퍼 크기 를 구하 십시오. 이것 은 시스템 페이지 크기 에 따라 설정 할 수 있 습 니 다. 보통 한 페이지 입 니 다.요청 헤더 의 크기 는 1k 를 초과 하지 않 습 니 다. 그러나 일반 시스템 의 페이지 가 1k 이상 이 어야 하기 때문에 페이지 크기 로 설정 합 니 다. 페이지 크기 는 명령 getconf PAGESIZE 로 가 져 올 수 있 습 니 다.

[root@web001 ~]# getconf PAGESIZE

4096

그러나 client header buffer size 가 4k 를 초과 하 는 경우 도 있 지만, client header buffer size 이 값 은 '시스템 페이지 크기' 로 설정 해 야 합 니 다.8. open file cache max = 65535 inactive = 60s; 이것 은 파일 을 열기 위해 캐 시 를 지정 합 니 다. 기본적으로 사용 되 지 않 습 니 다. max 는 캐 시 수량 을 지정 합 니 다. 파일 을 여 는 것 과 일치 하 는 것 을 권장 합 니 다. inactive 는 파일 이 요청 되 지 않 은 지 얼마나 지나 서 캐 시 를 삭제 하 는 것 을 말 합 니 다. 9. open file cache valid 80s. 이것 은 캐 시 를 얼마나 자주 검사 하 는 지 를 말 합 니 다. 10. open file cache min uses 1; open file cache 명령 의 inactive 매개 변 수 는 시간 내 에 파일 의 최소 사용 횟수 입 니 다. 이 숫자 를 초과 하면 파일 설명 자 는 캐 시 에서 열 려 있 습 니 다. 예 를 들 어 inactive 시간 내 에 한 번 도 사용 되 지 않 으 면 삭 제 됩 니 다.
커 널 매개 변수 최적화:

net.ipv4.tcp_max_tw_buckets = 6000

timewait 의 수량 은 기본적으로 180000 입 니 다.

net.ipv4.ip_local_port_range = 1024 65000

시스템 이 열 수 있 는 포트 범위 입 니 다.

net.ipv4.tcp_tw_recycle = 1

timewait 빠 른 회수 사용 하기.

net.ipv4.tcp_tw_reuse = 1

재 활용 을 시작 합 니 다. TIME - WAIT sockets 를 새로운 TCP 연결 에 다시 사용 할 수 있 습 니 다.

net.ipv4.tcp_syncookies = 1

SYN Cookies 를 켜 면 SYN 대기 열 이 넘 칠 때 cookies 를 사용 합 니 다.

net.core.somaxconn = 262144

웹 응용 프로그램 에서 listen 함수 의 backlog 기본 값 은 커 널 인자 의 net. core. somaxconn 을 128 로 제한 하고 nginx 가 정의 하 는 NGX LISTEN BACKLOG 는 기본 값 이 511 이 므 로 이 값 을 조정 할 필요 가 있 습 니 다.

net.core.netdev_max_backlog = 262144

모든 네트워크 인터페이스 에서 패 킷 을 받 는 속 도 는 커 널 이 이 패 킷 을 처리 하 는 속도 보다 빠 를 때 대기 열 에 보 내 는 패 킷 의 최대 수 를 허용 합 니 다.

net.ipv4.tcp_max_orphans = 262144

시스템 에서 최대 몇 개의 TCP 소켓 이 사용자 파일 핸들 에 연결 되 지 않 습 니 다. 이 숫자 를 초과 하면 고아 연결 이 즉시 복원 되 고 경고 메 시 지 를 출력 합 니 다. 이 제한 은 단순 한 DoS 공격 을 방지 하기 위 한 것 일 뿐 지나치게 의존 하거나 인위적으로 이 값 을 줄 일 수 없습니다. (메모 리 를 추가 하면)

net.ipv4.tcp_max_syn_backlog = 262144

클 라 이언 트 의 확인 정 보 를 받 지 못 한 연결 요청 의 최대 값 을 기록 합 니 다. 128 M 메모리 가 있 는 시스템 의 경우 부족 한 값 은 1024 이 고 작은 메모리 시스템 은 128 입 니 다.

net.ipv4.tcp_timestamps = 0

타임 스탬프 는 시리 얼 번호 의 와 인 딩 을 피 할 수 있 습 니 다. 1Gbps 의 링크 는 이전에 사 용 했 던 시리 얼 번 호 를 만 날 수 있 습 니 다. 타임 스탬프 는 커 널 에 이러한 '이상' 패 킷 을 받 아들 일 수 있 습 니 다. 이 패 키 지 를 꺼 야 합 니 다.

net.ipv4.tcp_synack_retries = 1

커 널 은 커 널 연결 을 위해 SYN 을 보 내 고 앞 SYN 에 응답 하 는 ACK 를 첨부 해 야 합 니 다. 즉, 세 번 의 악수 중 두 번 째 악 수 를 하 는 것 입 니 다. 커 널 이 연결 을 포기 하기 전에 SYN + ACK 가방 을 보 내 는 수량 을 결정 합 니 다.

net.ipv4.tcp_syn_retries = 1

커 널 이 연결 을 포기 하기 전에 SYN 패 키 지 를 보 내 는 수량 입 니 다.

net.ipv4.tcp_fin_timeout = 1

소켓 이 이 엔 드 에서 꺼 져 야 한다 면 이 매개 변 수 는 FIN - WAIT - 2 상 태 를 유지 하 는 시간 을 결정 합 니 다. 엔 드 에 오류 가 발생 하고 연결 을 영원히 닫 지 않 을 수 있 으 며, 예상 치 못 하 게 다운 되 었 습 니 다. 결 성 된 값 은 60 초 입 니 다. 2.2 커 널 의 보통 값 은 180 초 입 니 다. 3 이 설정 을 누 를 수 있 습 니 다. 단, 기계 가 가 벼 운 WEB 서버 라 하 더 라 도 대량의 죽음 으로 인 한 경우 가 있 습 니 다.소켓 으로 메모리 가 넘 칠 위험 이 있 습 니 다. FIN - WAIT - 2 의 위험성 은 FIN - WAIT - 1 보다 작 습 니 다. 최대 1.5K 메모리 만 먹 을 수 있 지만 생존 기간 이 길 기 때 문 입 니 다.

net.ipv4.tcp_keepalive_time = 30

keepalive 를 시작 할 때 TCP 에서 keepalive 메 시 지 를 보 내 는 빈도 입 니 다. 부족 한 시간 은 2 시간 입 니 다.