システム再起動後に ngix リロードが有効にならない理由の分析_PHP チュートリアル

システムの再起動後にngixのリロードが有効にならない理由の分析

システムの再起動後にngixのリロードが有効にならない理由の分析

これは、長い間私を悩ませてきた比較的まれな問題ですこの問題は非常に単純ですが、時間が経っても根本原因を見つけるのはまだ困難です。その分析プロセスを次のように共有します。

前提条件: Linux システムの起動プロセス、Nginx プロセスの起動プロセス、プロセス追跡について一定の理解を持っている必要があります。




1. Nginx リロード プロセスの分析:
公式 Web サイトのドキュメントを確認し、Nginx ソース コードを分析した結果、リロード プロセスは次の操作を実行したと大まかに結論付けることができます。


1、設定が正しいか確認
nginx -tに相当
2、ログファイルを開く
nginx -sopenに相当
ログファイルが多いため複数のファイルを開く必要がある
3、再ソケットをリッスンします
nginx の場合は同等です
このステップでは多くのものが初期化され、ハッシュ テーブルに焦点を当てます
4、古いワーカー プロセスを閉じます
nginx -s quit と同等です




2 番目、nginx プロセス分析
1 、まず nginx の 2 つのプロセスを理解します
マスター プロセス、root ユーザーによって開かれ、シグナルを受信し、ワーカー プロセスを管理します
ワーカー プロセス、nginx ユーザーによって開かれ、ワーカー プロセス、http リクエストの処理を担当します


2、starce はメイン プロセスを追跡しますnginx -s reloadが実行されている間に、チェックでスタックしていることがわかります。 リロードプロセスはnginxメインプロセスにHUPシグナルを送信するシステムであるため、ログファイルはメインプロセスによって追跡されます
# starce -p 2298
...
open("/data/wwwlogs/access.xxx.xxx.xxx .log", O_WRONLY|O_CREAT|O_APPEND, 0644) = -1 EMFILE (開いているファイルが多すぎます)
write(808 , "2016/02/17 09:50:22 [emerg] 2298"..., 124) = 124
....


3、プロンプトに従ってプロセスのシステム制限ファイルを見つけます


マスタープロセス制限
# cat /proc/2398/limits
ソフトリミットハードリミットユニットを制限
最大CPU時間無制限無制限秒
最大ファイルサイズ無制限無制限バイト
最大データサイズ無制限無制限バイト
最大スタックサイズ10485760無制限バイト
最大コアファイルサイズ 0 無制限バイト
最大常駐セット数 無制限 無制限バイト
最大プロセス数 127015 127015 プロセス
最大オープンファイル数 1024 4096 ファイル
最大ロックメモリ 65536 65536 バイト
最大アドレス空間 無制限 無制限バイト
最大ファイルロック数 無制限 無制限ロック数
最大保留中のシグナル127015 127015信号
マックスMSGQUEUEサイズ819200バイト819200バイト
マックスマックスマックス優先度0 0ハードリミットユニットの制限
最大 CPU 時間 無制限 無制限秒数
最大ファイル サイズ 無制限 無制限バイト
最大データ サイズ 無制限 無制限バイト
最大スタック サイズ 10485760 無制限バイト
最大コア ファイル サイズ 0 無制限バイト
最大常駐セット数 無制限 無制限バイト
最大プロセス数127015 127015 プロセス
最大オープンファイル数 409600 409600 ファイル
最大ロックメモリ数 65536 65536 バイト
最大アドレススペース無制限無制限バイト
最大ファイルロック数無制限無制限ロック
最大保留シグナル数 127015 127015 シグナル
最大メッセージキューサイズ 8 19200 819200 バイト
最大素敵優先度 0 0
最大リアルタイム優先度 0 0
最大リアルタイムタイムアウト 無制限 無制限 us




補足エラーログ:
2 016/02/ 17 10:48:05 [notice] 47386#0: signal process開始
2016/02/ 17 10:48:05 [emerg] 2298#0: open() "/data/wwwlogs/access_xxx.xxx.xxx.log " が失敗しました (24: 開いているファイルが多すぎます)




3、解決策
1、制限を変更します
一般的には、次の 3 つの側面から調整します。
最初: nginx.conf パラメーターの計画と設定
worker_rlimit_nofile: 単一のジョブを制限する
プロセスによって開かれるファイルの最大数:
オンライン構成に問題はありません
worker_rlimit_nofile 409600;


2番目: システムレベルの検査と設定
つまり、/etc/security/limits.confの構成と変更については、Linuxシステムリソース制限の概要を参照してください
オンライン構成に問題はありません
*ソフト nofile 655350
* ハード nofile 655350


3 番目: カーネルレベルのチェックと設定:
fs.file-max 値のサイズ設定:
オンライン構成は比較的大きいです
file-max = 6553600
注: デフォルト。 file-max の値はシステム メモリの約 10% (システム メモリは kb 単位で計算されます)




2、検証が有効になります
初期段階では上記の設定になっていることが分かりましたが、サーバーを再起動するとメインプロセスの制限が変更されていないことがわかりますが、サーバーにログインした後に表示されるかどうかはわかりません。ターミナルで ulimit -n を実行するか、nginx メインプロセスを閉じた後に nginx を再起動すると、効果が現れます。このことから、問題は Linux システムの起動プロセスにある可能性があります。つまり、nginx メインプロセスの起動時に、上記の制限設定は有効になりません。後で情報を調べたところ、limits.conf 設定はシステム起動後にログインが実行されるまで有効にならないため、順序を調整する必要があることがわかりました。
実際の状況に基づく、システムの起動プロセスは次のとおりです。
1. /etc/inittab を読み取り、デフォルトのレベルを読み取ります。
2. 初期化システム スクリプトを実行します。 .d/rc.sysinit を使用してスクリプトを初期化します
3. 次に、/etc/rc.d/rc スクリプトを実行します
4. このスクリプトは、最後のスクリプトです。起動プロセス中に開始されます。
最後に/bin/loginが実行されてユーザーがログインします。この時点でシステムの起動処理は完了しており、/etc/profile、~/.bash_profile、~/.bashrc 等はログイン後にのみ実行されます。このときの ulimit -n で求められる値は、 nginxプロセスが開始されたときの値。
デフォルトでは、limits.conf 設定ファイルはユーザーがログインしたときに有効になります。これは nginx プロセスの開始よりも後で有効になります。これより前に設定を有効にするには、次のように設定を補足する必要があります:
cat /etc/rc.local
ulimit -HSn 655350 (nginx の開始前に実行されることに注意してください)
/usr/local/nginx/sbin/nginx






4 番目の補足的な最適化


には、主に関連するパラメーター。
1. カーネルの最適化
iptable 自体がカーネルのパフォーマンスに影響を与えるため、Net.ipv4.tcp_max_tw_buckets を大きく変更する必要があります
# ss -an |awk '{print $1}'|sort |uniq -c |sort -rn
15415 ESTAB
12979 TIME-WAIT
1961 FIN-WAIT-2
501 FIN-WAIT-1
234 LAST-ACK
32 SYN-RECV
11 リッスン
3 クローズ
1 SYN-SENT
1 州
1 CLOSE-WAIT


オンライン構成の変更は次のとおりです:
net.ipv4.tcp_max_tw_buckets = 18000


2、nginx の最適化
主にハッシュ テーブル、その他の構成は最適化されており、ハッシュ テーブルには次のタイプがあります
server_names_hash を追加できます
map_hash は追加できます
types_hash を追加するだけで十分です
リクエストヘッダーは考慮されません
variables_hash で十分です


オンライン設定は次のとおりです:
server_names_hash_max_size 512000;
server_names_hash_bucket_size 64; )
map_hash_max_size 204800 ;
map_hash_bucket_size 64 ; (デフォルト)

http://www.bkjia.com/PHPjc/1103189.htmlwww.bkjia.com本当http://www.bkjia.com/PHPjc/1103189.html技術記事システムの再起動後に ngix のリロードが有効にならない理由の分析 システムの再起動後に ngix のリロードが有効にならない理由の分析 この問題は比較的まれですが、私を悩ませてきました。とてもシンプルです...