検索

ホームページ >運用・保守 >Nginx >nginx パフォーマンス最適化のヒントの共有

nginx パフォーマンス最適化のヒントの共有

王林
王林転載
2021-03-05 15:19:193447ブラウズ

nginx パフォーマンス最適化のヒントの共有

この記事では、nginx のパフォーマンスを最適化するためのヒントをすべての人に向けて紹介します。非常に実用的で、困っている友人のお役に立てれば幸いです。

1. nginx パフォーマンス最適化のための非常に重要な設定オプション

1. work_processes 8;

nginx プロセスの数は、CPU の数に応じて指定することをお勧めします。通常はその倍数になります (たとえば、2 つのクアッドコア CPU は 8 としてカウントされます)。

2.worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

Allocate cpu to each process. 上記の例では、8 つのプロセスが 8 つの CPU に割り当てられています。または、プロセスを複数の CPU に割り当てます。

3.worker_rlimit_nofile 65535;

この命令は、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. epoll を使用します;

epoll の I/O モデルを使用します

(追加説明:

Apache と同様に、nginx にはオペレーティング システムごとに異なるイベント モデルがあります

A) 標準イベント モデル

標準イベント モデルに属するものを選択してポーリングします。システムにはこれ以上効率的な方法はなく、nginx は選択またはポーリングを選択します

B) 効率的なイベント モデル

Kqueue: FreeBSD 4.1、OpenBSD 2.9、NetBSD 2.0、および MacOS X で使用されます。デュアル処理を使用します。 kqueue を使用する MacOS X システムでは、カーネル クラッシュが発生する可能性があります。
Epoll: Linux カーネル バージョン 2.6 以降のシステムで使用されます。
/dev/poll: Solaris 7 11/99、HP/UX 11.22 (イベントポート)、IRIX 6.5.15、および Tru64 UNIX 5.1A で使用されます。
イベントポート: Solaris 10 で使用されます。カーネルのクラッシュを防ぐために、セキュリティ パッチをインストールする必要があります。 )

5.worker_connections 65535;

各プロセスに許可される接続の最大数理論的には、各 nginx サーバーの最大接続数は、worker_processes*worker_connections です。

6. keepalive_timeout 60;

キープアライブ タイムアウト。

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 パラメータ内のファイルの最小使用回数この数を超えると、ファイル記述子は常にキャッシュ内で開かれます, 上記の例のように、ファイルが非アクティブ時間内に一度も使用されなかった場合、そのファイルは削除されます。

2. カーネル パラメーターの最適化について: 

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
web 应用中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
记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M 内存的系统而言，缺省值是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 小时。

3. 以下に完全なカーネル最適化設定を投稿してください: 

#CentOS5.5中可以将所有内容清空直接替换为如下内容:
vi /etc/sysctl.conf 

   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.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 65000

#使配置立即生效可使用如下命令：
 /sbin/sysctl -p

(学習ビデオの共有: php ビデオ チュートリアル)

4. 以下は、システム接続数の最適化についてです。

linux のデフォルトのオープン ファイルと最大ユーザー プロセスは 1024

#ulimit -n   
    1024
#ulimit Cu   
    1024

問題の説明:

サーバーが同時に開くことができるのは 1024 個のファイルのみであり、1024 個のユーザー プロセスを処理できることを説明します。

現在のシステムのすべての制限値を表示するには、ulimit -a を使用します。 ulimit -n を使用すると、開いているファイルの現在の最大数が表示されます。

新しくインストールした Linux はデフォルトで 1024 しかないため、負荷の高いサーバーとして使用すると、開いているファイルが多すぎるというエラーが発生しやすくなります。したがって、それを大きくする必要があります。

解決策:

ulimit Cn 65535 の使用はすぐに変更できますが、再起動後は無効になります。 (ulimit -SHn 65535 は ulimit -n 65535 と同等、-S はソフト、-H はハードを意味することに注意してください)

3 つの変更方法があります:

1. / etc/rc. local に ulimit -SHn 65535
の行を追加します. /etc/profile に ulimit -SHn 65535
3 の行を追加します. /etc/security/limits.conf の最後に追加します: 

* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535

具体的にどれを使用しますか?最初の方法は CentOS では効果がありません、3 番目の方法は効果があります、2 番目の方法は Debian では効果があります

      # ulimit -n        65535

      # ulimit -u        65535

注: ulimit コマンドそれ自体はソフトウェアとハ​​ードウェアに分かれています。設定、ハードの場合は -H を追加、ソフトの場合は -S を追加、デフォルトの表示はソフト リミットです。

 soft 限制指的是当前系统生效的设置值。 hard 限制值可以被普通用户降低。但是不能增加。 soft 限制不能设置的比 hard 限制更高。 只有 root 用户才能够增加 hard 限制值。

五、下面是一个简单的nginx 配置文件：

user 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 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 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 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)$
         {
          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: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 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，可以修改配置文件中的以下值：
<value name=”max_children”>60</value>
同时处理的并发请求数，即它将开启最多60 个子线程来处理并发连接。
<value name=”rlimit_files”>102400</value>
最多打开文件数。
<value name=”max_requests”>204800</value>
每个进程在重置之前能够执行的最多请求数。

相关推荐：nginx教程

以上がnginx パフォーマンス最適化のヒントの共有の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明：
この記事はcnblogs.comで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。
前の記事：nginx を使用して静的リソースをデプロイする方法次の記事：nginx を使用して静的リソースをデプロイする方法

関連記事

続きを見る