nginx – Beispiel für eine Optimierungskonfiguration

http://www.lvtao.net/tool/nginx-config-10w.html
Optimierung in der Nginx-Direktive (Konfigurationsdatei) worker_processes 8;

Es wird empfohlen, die Anzahl der Nginx-Prozesse entsprechend der Anzahl der CPUs anzugeben, normalerweise ein Vielfaches davon.

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

Weisen Sie jedem Prozess eine CPU zu. Im obigen Beispiel sind 8 Prozesse 8 CPUs zugeordnet. Natürlich können Sie mehrere schreiben oder einen Prozess mehreren CPUs zuweisen.

worker_rlimit_nofile 102400;

Dieser Befehl bezieht sich auf die maximale Anzahl der von einem Nginx-Prozess geöffneten Dateideskriptoren. Der theoretische Wert sollte die maximale Anzahl geöffneter Dateien (ulimit -n) geteilt durch die Anzahl der Nginx-Prozesse sein Die Nginx-Zuweisungsanforderung ist nicht so einheitlich, daher ist es besser, mit dem Wert von ulimit -n konsistent zu sein.

use epoll;

Die Verwendung des E/A-Modells von epoll versteht sich von selbst.

worker_connections 102400;

Die maximal zulässige Anzahl von Verbindungen pro Prozess beträgt theoretisch worker_processes*worker_connections.

keepalive_timeout 60;

Keepalive-Timeout.

client_header_buffer_size 4k;

Die Puffergröße des Client-Anfrage-Headers kann entsprechend der Paging-Größe Ihres Systems festgelegt werden. Im Allgemeinen überschreitet die Header-Größe einer Anfrage 1 KB nicht, da die allgemeine System-Paging-Größe jedoch größer ist als 1 KB, daher wird dies auf die Paging-Größe eingestellt. Die Paging-Größe kann mit dem Befehl getconf PAGESIZE ermittelt werden.

open_file_cache max=102400 inactive=20s;

Dies gibt den Cache für geöffnete Dateien an. Es wird empfohlen, die Anzahl der geöffneten Dateien konsistent zu halten Die Datei wurde nicht angefordert, bevor der Cache gelöscht wurde.

open_file_cache_valid 30s;

Dies bezieht sich darauf, wie oft zwischengespeicherte gültige Informationen überprüft werden sollen.

open_file_cache_min_uses 1;

Die Mindestanzahl, wie oft die Datei während des inaktiven Parameters in der open_file_cache-Anweisung verwendet wird. Wenn diese Zahl überschritten wird, wird der Dateideskriptor immer im Cache geöffnet Innerhalb der inaktiven Zeit befindet sich eine Datei. Sobald sie nicht verwendet wird, wird sie entfernt.

Optimierung der Kernel-Parameter net.ipv4.tcp_max_tw_buckets = 6000

Die Anzahl der Wartezeiten, der Standardwert ist 180000.

net.ipv4.ip_local_port_range = 1024 65000

Der Bereich der Ports, die das System öffnen darf.

net.ipv4.tcp_tw_recycle = 1

Aktivieren Sie Timewait, schnelles Recycling.

net.ipv4.tcp_tw_reuse = 1

Wiederverwendung aktivieren. Ermöglicht die Wiederverwendung von TIME-WAIT-Sockets für neue TCP-Verbindungen.

net.ipv4.tcp_syncookies = 1

SYN-Cookies aktivieren Wenn die SYN-Warteschlange überläuft, aktivieren Sie Cookies, um damit umzugehen.

net.core.somaxconn = 262144

Der Rückstand der Listen-Funktion in der Webanwendung begrenzt den net.core.somaxconn unserer Kernel-Parameter standardmäßig auf 128, und der von nginx definierte NGX_LISTEN_BACKLOG ist standardmäßig auf 511 festgelegt, daher ist dies erforderlich um diesen Wert anzupassen.

net.core.netdev_max_backlog = 262144

Die maximale Anzahl von Paketen, die in die Warteschlange gestellt werden dürfen, wenn jede Netzwerkschnittstelle Pakete schneller empfängt, als der Kernel sie verarbeiten kann.

net.ipv4.tcp_max_orphans = 262144

Die maximale Anzahl von TCP-Sockets im System, die keinem Benutzerdatei-Handle zugeordnet sind. Wenn diese Zahl überschritten wird, wird die verwaiste Verbindung sofort zurückgesetzt und eine Warnmeldung ausgegeben. Diese Grenze dient nur der Verhinderung einfacher DoS-Angriffe. Sie können sich nicht zu sehr darauf verlassen oder diesen Wert künstlich verringern. Sie sollten diesen Wert erhöhen (wenn Sie den Speicher erhöhen).

net.ipv4.tcp_max_syn_backlog = 262144

Die maximale Anzahl der aufgezeichneten Verbindungsanfragen, die noch keine Bestätigung vom Client erhalten haben. Für Systeme mit 128 MB Speicher ist der Standardwert 1024 und für Systeme mit kleinem Speicher 128.

net.ipv4.tcp_timestamps = 0

Mit einem Zeitstempel kann das Umbrechen von Seriennummern vermieden werden. Bei einer 1-Gbit/s-Verbindung werden Sie auf jeden Fall auf Sequenznummern stoßen, die bereits zuvor verwendet wurden. Der Zeitstempel ermöglicht es dem Kernel, solche „abnormalen“ Pakete zu akzeptieren. Es muss hier ausgeschaltet werden.

net.ipv4.tcp_synack_retries = 1

Um eine Verbindung zum Peer zu öffnen, muss der Kernel ein SYN mit einer ACK als Antwort auf das vorherige SYN senden. Dies ist der zweite Handschlag beim sogenannten Drei-Wege-Handschlag. Diese Einstellung bestimmt die Anzahl der SYN+ACK-Pakete, die der Kernel sendet, bevor die Verbindung aufgegeben wird.

net.ipv4.tcp_syn_retries = 1

Die Anzahl der gesendeten SYN-Pakete, bevor der Kernel den Verbindungsaufbau aufgibt.

net.ipv4.tcp_fin_timeout = 1

Wenn der Socket vom lokalen Ende geschlossen werden soll, bestimmt dieser Parameter, wie lange er im FIN-WAIT-2-Zustand bleibt. Der Peer kann Fehler machen und die Verbindung niemals schließen oder sogar unerwartet abstürzen. Der Standardwert beträgt 60 Sekunden. Der übliche Wert für den 2.2-Kernel beträgt 180 Sekunden. Sie können diese Einstellung drücken, aber denken Sie daran, dass aufgrund einer großen Anzahl toter Sockets die Gefahr eines Speicherüberlaufs besteht -2 ist weniger gefährlich als FIN-WAIT-1, da es nur bis zu 1,5 KB Speicher beanspruchen kann, aber ihre Überlebenszeit ist länger.

net.ipv4.tcp_keepalive_time = 30

Wenn Keepalive aktiviert ist, die Häufigkeit, mit der TCP Keepalive-Nachrichten sendet. Der Standardwert beträgt 2 Stunden.

Eine vollständige Kernel-Optimierungskonfigurationnet.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.wmem_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 65000Eine einfache Nginx-Optimierungskonfigurationsdateiuser www www; worker_processes 8; worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000; error_log /www/log/nginx_error.log crit; pid /usr/local/nginx/nginx.pid; worker_rlimit_nofile 204800; events { use 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 2k; 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_cache levels=1:2 keys_zone=TEST:10m inactive=5m; fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; fastcgi_buffer_size 16k; fastcgi_buffers 16 16k; fastcgi_busy_buffers_size 16k; fastcgi_temp_file_write_size 16k; fastcgi_cache TEST; fastcgi_cache_valid 200 302 1h; fastcgi_cache_valid 301 1d; fastcgi_cache_valid any 1m; fastcgi_cache_min_uses 1; fastcgi_cache_use_stale error timeout invalid_header http_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 text/plain application/x-javascript text/css application/xml; gzip_vary on; server { listen 8080; server_name ad.test.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)$ { expires 30d; } log_format access '$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 /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;

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

fastcgi_connect_timeout 300;

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

fastcgi_send_timeout 300;

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

fastcgi_read_timeout 300;

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

fastcgi_buffer_size 16k;

指定读取FastCGI应答第一部分需要用多大的缓冲区，这里可以设置为fastcgi_buffers指令指定的缓冲区大小，上面的指令指定它将使用1 个16k的缓冲区去读取应答的第一部分，即应答头，其实这个应答头一般情况下都很小（不会超过1k），但是你如果在fastcgi_buffers指令中 指定了缓冲区的大小，那么它也会分配一个fastcgi_buffers指定的缓冲区大小去缓存。

fastcgi_buffers 16 16k;

指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答，如上所示，如果一个php脚本所产生的页面大小为256k，则会为其分配16个16k的缓 冲区来缓存，如果大于256k，增大于256k的部分会缓存到fastcgi_temp指定的路径中，当然这对服务器负载来说是不明智的方案，因为内存中 处理数据速度要快于硬盘，通常这个值的设置应该选择一个你的站点中的php脚本所产生的页面大小的中间值，比如你的站点大部分脚本所产生的页面大小为 256k就可以把这个值设置为16 16k，或者4 64k 或者64 4k，但很显然，后两种并不是好的设置方法，因为如果产生的页面只有32k，如果用4 64k它会分配1个64k的缓冲区去缓存，而如果使用64 4k它会分配8个4k的缓冲区去缓存，而如果使用16 16k则它会分配2个16k去缓存页面，这样看起来似乎更加合理。

fastcgi_busy_buffers_size 32k;

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

fastcgi_temp_file_write_size 32k;

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

fastcgi_cache TEST

开启FastCGI缓存并且为其制定一个名称。个人感觉开启缓存非常有用，可以有效降低CPU负载，并且防止502错误。但是这个缓存会引起很多问题，因为它缓存的是动态页面。具体使用还需根据自己的需求。

fastcgi_cache_valid 200 302 1h; fastcgi_cache_valid 301 1d; fastcgi_cache_valid any 1m;

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

fastcgi_cache_min_uses 1;

缓存在fastcgi_cache_path指令inactive参数值时间内的最少使用次数，如上例，如果在5分钟内某文件1次也没有被使用，那么这个文件将被移除。

fastcgi_cache_use_stale error timeout invalid_header http_500;

不知道这个参数的作用，猜想应该是让nginx知道哪些类型的缓存是没用的。 以上为nginx中FastCGI相关参数，另外，FastCGI自身也有一些配置需要进行优化，如果你使用php-fpm来管理FastCGI，可以修改配置文件中的以下值：

60

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

102400

最多打开文件数。

204800

每个进程在重置之前能够执行的最多请求数。

以上就介绍了nginx--优化配置示例，包括了方面的内容，希望对PHP教程有兴趣的朋友有所帮助。