nginx 높은 동시성 구성 매개변수에 대한 자세한 설명

1. 일반적으로 nginx 구성 파일의 다음 항목은 최적화에 더 효과적입니다.

1.worker_processes 8;

nginx 프로세스 번호에 따라 지정하는 것이 좋습니다. 예를 들어 2A 쿼드 코어 CPU는 8개로 계산됩니다.

2.worker_cpu_affinity 00000001 0000001000000100 00001000 00010000 00100000 01000000 10000000;

위의 예에서는 8개의 프로세스가 8개의 CPU에 할당됩니다. 여러 개를 쓰거나 하나의
프로세스를 여러 CPU에 할당할 수 있습니다.

3.worker_rlimit_nofile65535;

이 명령은 nginx 프로세스에서 열린 최대 파일 설명자 수를 나타냅니다. 이론적인 값은 최대 열린 파일 수(ulimit -n)를 nginx 프로세스 수로 나눈 값입니다. nginx 할당 요청은 그다지 균일하지 않으므로 ulimit -n 값으로 일관성을 유지하는 것이 좋습니다.

이제 Linux 2.6 커널에서 열려 있는 파일 수는 65535이고 이에 따라 Worker_rlimit_nofile은 65535로 채워져야 합니다.

이것은 nginx 스케줄링 시 프로세스에 대한 요청 할당이 균형이 맞지 않기 때문이므로 10240을 입력하고 총 동시성이 30,000~40,000에 도달하면 프로세스 수가 10240을 초과할 수 있으며 502 오류가 반환됩니다.

Linux 시스템 파일 설명자를 보는 방법:

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

fs.file-max = 789972

fs.file-nr = 510 0 789972

4 . useepoll;

epoll의 I/O 모델 사용

(

추가 설명:

apache와 유사하게 nginx는 운영 체제마다 다른 이벤트 모델을 갖습니다.

A) 표준 이벤트 모델

선택, Poll은 표준 이벤트에 속합니다. 모델 현재 시스템에 더 효율적인 방법이 없으면 nginx는 선택 또는 폴링을 선택합니다. B) 효율적인 이벤트 모델 Kqueue: FreeBSD 4.1+, OpenBSD 2.9+, NetBSD2.0 및 MacOS X에서 사용됩니다. kqueue를 사용하는 프로세서는 커널 패닉을 일으킬 수 있습니다.
Epoll: Linux 커널 버전 2.6 이상이 설치된 시스템에서 사용됩니다.



/dev/poll: Solaris 7 11/99+, HP/UX 11.22+(eventport), IRIX 6.5.15+ 및 Tru64 UNIX 5.1A+에서 사용됩니다.

이벤트 포트: Solaris 10에서 사용됩니다. 커널 충돌을 방지하려면 보안 패치를 설치해야 합니다.

)

5.worker_connections65535;

프로세스당 허용되는 최대 연결 수는 이론적으로 nginx 서버당 최대 연결 수입니다.

6. keepalive_timeout60;

keepalive 시간 초과.

7.client_header_buffer_size4k;

클라이언트 요청 헤더의 버퍼 크기입니다. 이는 시스템 페이징 크기에 따라 설정될 수 있습니다. 일반적으로 요청 헤더의 크기는 1k를 초과하지 않지만 일반 시스템 페이징은 다음보다 큽니다. 1k, 여기서는 페이징 크기로 설정되었습니다.

페이징 크기는 getconf PAGESIZE 명령을 사용하여 얻을 수 있습니다.

[root@web001 ~]# getconf PAGESIZE

4096

그러나 client_header_buffer_size가 4k를 초과하는 경우도 있지만 client_header_buffer_size 값은 "시스템 페이징 크기"의 정수배로 설정되어야 합니다.

8. Open_file_cachemax=65535 inactive=60s;

이것은 열린 파일에 대한 캐시를 지정합니다. 이는 기본적으로 활성화되지 않습니다. 비활성 참조 수와 일치하는 것이 좋습니다. 요청 후 파일이 캐시되지 않은 기간.

9.open_file_cache_valid80s;

캐시된 유효한 정보를 얼마나 자주 확인하는지를 나타냅니다.

10.open_file_cache_min_uses1;

open_file_cache 명령의 비활성 매개변수 동안 파일의 최소 사용 횟수가 초과되면 위의 예와 같이 파일 설명자가 항상 캐시에 열립니다. 비활성 시간에 한 번 파일을 사용하지 않으면 제거됩니다.

2. 커널 매개변수 최적화 관련:

net.ipv4.tcp_max_tw_buckets = 6000

대기 시간 수, 기본값은 180000입니다.

net.ipv4.ip_local_port_range = 1024 65000

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

net.ipv4.tcp_tw_recycle = 1

시간 대기 빠른 재활용을 활성화합니다.

net.ipv4.tcp_tw_reuse = 1

재사용을 활성화합니다. 새로운 TCP 연결에 TIME-WAIT 소켓을 재사용할 수 있습니다.

net.ipv4.tcp_syncookies = 1

SYN 쿠키를 활성화합니다. SYN 대기 대기열이 오버플로되면 쿠키를 활성화하여 이를 처리합니다.

net.core.somaxconn = 262144

웹 애플리케이션의 수신 기능 백로그는 커널 매개변수의 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

클라이언트로부터 아직 승인을 받지 못한 기록된 연결 요청의 최대 개수입니다. 메모리가 128M인 시스템의 경우 기본값은 1024이고, 메모리가 작은 시스템의 경우 기본값은 128입니다.

net.ipv4.tcp_timestamps = 0

타임스탬프는 시퀀스 번호 줄 바꿈을 방지할 수 있습니다. 1Gbps 링크는 확실히 이전에 사용되었던 시퀀스 번호를 만나게 됩니다. 타임스탬프를 사용하면 커널이 이러한 "비정상적인" 패킷을 허용할 수 있습니다. 여기서는 꺼야 합니다.

net.ipv4.tcp_synack_retries = 1

피어에 대한 연결을 열려면 커널은 이전 SYN에 대한 응답으로 ACK와 함께 SYN을 보내야 합니다. 이른바 삼자악수 중 두 번째 악수다. 이 설정은 연결을 포기하기 전에 커널이 보내는 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는 최대 1.5K의 메모리만 사용할 수 있기 때문에 FIN-WAIT-1보다 덜 위험하지만 수명이 더 깁니다.

net.ipv4.tcp_keepalive_time = 30

keepalive가 활성화되면 TCP가 keepalive 메시지를 보내는 빈도입니다. 기본값은 2시간입니다.

3. 전체 커널 최적화 설정은 아래에 게시되어 있습니다:

vi /etc/sysctl.conf CentOS5.5에서는 모든 내용을 지우고 다음 내용으로 직접 대체할 수 있습니다:

net.ipv4.ip_forward = 0
net.ipv4 .conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 4194304
net .ipv4.tcp_wmem = 4096 16384 4194304
net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.w mem_max = 16777216
net.core.netdev_max_backlog = 262144
net .core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net .ipv4.tcp_syn_retries = 1
net.ipv4 .tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024 65000

use 구성을 즉시 적용하려면 다음 명령을 사용할 수 있습니다:
/sbin/sysctl -p

4. 다음은 시스템 연결 수 최적화에 관한 것입니다.

열린 파일의 기본값과 Linux의 최대 사용자 프로세스는 1024

#ulimit -n

1024

#ulimit –u

1024

문제 설명: 설명 서버는 동시에 1024개의 파일만 열 수 있도록 허용하고 1024개의 사용자 프로세스를 처리합니다

현재 시스템의 모든 제한 값을 보려면 ulimit -a를 사용하고, 현재 열린 파일의 최대 수를 보려면 ulimit -n을 사용하십시오.

새로 설치된 Linux에는 기본적으로 1024만 있습니다. 로드가 많은 서버로 사용하면 열려 있는 파일이 너무 많습니다. 따라서 더 크게 만들어야 합니다.

해결 방법:

ulimit –n 65535를 사용하여 즉시 수정하지만 다시 시작한 후에는 유효하지 않습니다. (ulimit -SHn 65535는 ulimit-n 65535와 동일하며 -S는 소프트, -H는 하드를 나타냅니다.)

세 가지 수정 방법이 있습니다.

1 /에 ulimit -SHn 65535 행을 추가합니다. etc/rc.local
2 /etc/profile
3에 ulimit -SHn 65535 줄을 추가합니다. /etc/security/limits.conf 끝에 추가합니다:

* Soft nofile 65535
* hard nofile 65535
* Soft nproc 65535
* hard nproc 65535

어떤 방법을 구체적으로 사용해야 할까요? 첫 번째 방법은 CentOS에서는 효과가 없고, 세 번째 방법은 효과가 있으며, 두 번째 방법은 Debian에서 효과가 있습니다

# ulimit -n

65535

# ulimit -u

65535

참고: ulimit 명령 자체에는 소프트 및 하드 설정이 있습니다. 하드에 -H를 추가하고 소프트에 -S를 추가합니다. 기본 표시는 소프트 제한입니다

소프트 제한을 나타냅니다. 현재 시스템 값에 적용되는 설정입니다. 하드 제한 값은 일반 사용자가 낮출 수 있습니다. 그러나 늘릴 수는 없습니다. 소프트 제한은 하드 제한보다 높게 설정할 수 없습니다. 루트 사용자만 하드 제한 값을 늘릴 수 있습니다.

5 다음은 간단한 nginx 구성 파일입니다.

사용자 www www;
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 0001000000100000
01000000;
error_log /www/log/nginx_error.log crit;
pid /usr/local/nginx/nginx.pid;
worker_rlimit_nofile 204800;
이벤트
{
epoll 사용;
worker_connections 204800;
}
http
{
include mime.types;
default_type application/octet-stream;
charset utf-8;
server_names_hash_bucket_size 128;
client_header_buffer_size 2 k;
large_client_header_buffers 4 4k;
client_max_body_size 8m;
sendfile on;
tcp_nopush on;
keepalive_timeout 60;
fastcgi_cache_path /usr/local/nginx/fastcgi_cachelevels=1:2
keys_zone=TEST:10m
inactive=5m;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 4k;
fastcgi_buffers 8 4k;
fastcgi_busy_buffers_size 8k;
fastcgi_temp_file_write_size 8k;
fastcgi_cache TEST;
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid 모든 1m;
fastcgi_cache_min_uses 1;
fastcgi_cache_use_stale 오류 시간 초과 valid_headerhttp_500;
open_file_cache max=204800 inactive=20s;
open_file_cache_min_uses 1;
open_file_cache_valid 30s;
tcp_nodelay on;
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1 .0;
gzip_comp_level 2;
gzip_types 텍스트/일반 애플리케이션/x -javascript text/cssapplication/xml;
gzip_vary on;
server
{
listen 8080;
server_name backup.aiju.com;
index index.php index.htm;
root /www/html/;
location /status
{
stub_status on;
}
location ~ .*.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fcgi.conf;
}
location ~ .*. (gif|jpg|jpeg|png|bmp|swf|js|css)$
{
30일 만료;
}
log_format 액세스 '$remote_addr -- $remote_user [$time_local]"$request" '
'$status $ body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';
access_log /www/log/access.log access;
}
}

六、关于FastCGI 적几个指令：

fastcgi_cache_path /us r/로컬 /nginx/fastcgi_cache 레벨=1:2keys_zone=TEST:10minactive=5m;

这个指令为FastCGI 缓存指定一个路径，目录结构等级字，关键区域存储时间와비活动删除时间。

fastcgi_connect_timeout 300;

指정连接到后端FastCGI 的超时时间。

fastcgi_send_timeout 300;

向FastCGI 传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI 传送请求的超时时间。

fastcgi_read_timeout 300;

接收FastCGI는 应答的超时时间，这个值是指已经完成两次握手后接收FastCGI는 应答的超时时间。

fastcgi_buffer_size 4k;

指定读取FastCGI应答第一分需要는 더 큰 규모의 缓冲区, 一般第一分分应答不会를 사용합니다.超过1k,由于页면大小为4k,所以这里设置为4k。

fastcgi_buffers 8 4k;

指定本地需要 용도에 더 많은 缓冲区来缓冲FastCGI的应答。

fastcgi_busy_buffers_size 8k;

这个指令我也不知道是做什么用，只知道默认值是fastcgi_buffers 의 两倍。

fastcgi_temp_file_write_size 8k;

현재 写入fastcgi_temp_path 时将用多大数据块，默认值是fastcgi_buffers 的两倍。

fastcgi_cache TEST

开启FastCGI 缓存并且为其 제조사는 个人感觉开启缓存不常有，可以有效降低CPU 负载，并且防止502 错误。

fastcgi_cache_valid 200 302 1시간;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid 모든 1분;

为指정적应答代码指定缓存时间，如上例中将200，302 应答缓存一小时，301 应答缓存1 天，其他为1 分钟。

fastcgi_cache_min_uses 1;

缓存재fastcgi_cache_path가 비활성 상태입니다.如上例，如果는 5분 단위로 1次也没有被使用，那么这个文件将被移除。

fastcgi_cache_use_stale error timeout valid_headerhttp_500;

不知道这个参数의 작품, 猜想应该是让nginx 知道哪些类型의缓存是没사용용.以上为nginx 中FastCGI상关参数,另외,FastCGI 자체가 一些配置需要进行优化,如果你使사용php-fpm来管리FastCGI,可以修改配置文件中的以下值：

同时处理的并发请求数，即它将开启最多60 个子线程来处理并发连接。

102400

最多打开文件数。

204800

每个进程十置の前能够执行的最多请求数。🎜

위 내용은 nginx 높은 동시성 구성 매개변수에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!