PHP-CGI処理CPU100%とfile_get_contents関数の関係_PHPチュートリアル

Nginx および PHP-CGI (php-fpm) Web サービスを実行している Linux サーバーでシステム負荷が突然増加することがあります。top コマンドを使用して、多くの php-cgi プロセスの CPU 使用率が 100% に近いことを確認します。その後、追跡を通じて、この種の状況の発生は PHP の file_get_contents() 関数と密接に関係していることがわかりました。

大規模および中規模の Web サイトでは、HTTP プロトコルに基づく API インターフェイス呼び出しが一般的です。 PHP プログラマーは、URL の返されたコンテンツを取得するために、シンプルで便利な file_get_contents("http://example.com/") 関数を使用することを好みますが、Web サイト http://example.com/ の応答が遅い場合は、file_get_contents(. " ) は常にそこでスタックし、タイムアウトしません。

php.ini には、PHP スクリプトの最大実行時間を設定できるパラメータ max_execution_time があることはわかっていますが、php-cgi (php-fpm) では、このパラメータは有効になりません。 PHP スクリプトの最大実行時間を実際に制御できるのは、php-fpm.conf 構成ファイル内の次のパラメーターです:
ワーカー プロセスが終了するまでの 1 つのリクエストを処理するためのタイムアウト (秒) は、次の場合に使用する必要があります。 max_execution_time' ini オプションは何らかの理由でスクリプトの実行を停止しません '0s' means 'off' 0s デフォルト値は 0 秒で、PHP スクリプトが実行を継続することを意味します。このように、すべての php-cgi プロセスが file_get_contents() 関数でスタックすると、この Nginx+PHP Web サーバーは新しい PHP リクエストを処理できなくなり、Nginx はユーザーに「502 Bad Gateway」を返します。 PHP スクリプトの最大実行時間を設定するにはこのパラメータを変更する必要がありますが、根本的な原因ではなく症状を治療するだけです。たとえば、30s に変更された場合、file_get_contents() が Web コンテンツの取得に遅い場合、これは 150 php-cgi プロセスが 1 秒あたり 5 ファイルしか処理できないことを意味します。 .リクエストの場合、Webサーバーでも「502 Bad Gateway」を回避するのは困難です。

完全な解決策を達成するには、PHP プログラマが file_get_contents("http://example.com/") を直接使用する習慣を変更できるようにするだけですが、それをわずかに変更し、タイムアウトを追加し、次のメソッドを使用して HTTP を実装します。 GET リクエスト。それが面倒な場合は、次のコードを自分で関数にカプセル化することもできます。
array( 'timeout' => 1 //タイムアウトを秒単位で設定します) ) ); file_get_contents("http://example.com/", 0, $ctx); もちろん、php -CGI が発生します。プロセス CPU 100% だけが原因ではないので、file_get_contents() 関数が原因であるかどうかを判断するにはどうすればよいでしょうか。

まず、top コマンドを使用して、CPU 使用率が高い php-cgi プロセスを表示します。

トップ - 724 日、10:34:18 アップ、21:01、3 ユーザー、負荷平均: 17.86、11.16、7.69
タスク: 合計 561、実行中 15、スリープ 546、停止 0、ゾンビ 0
CPU: 5.9%us、4.2%sy、0.0%ni、89.4%id、0.2%wa、0.0%hi、0.2%si、0.0%st
メモリ: 合計 8100996k、使用済み 4320108k、空き 3780888k、バッファー 772572k
スワップ: 819310合計8,000 、50776k 使用、8142332k 空き、412088k キャッシュ

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10747 www 18 0 360m 22m 12m R 100.6 0.3 0:02.60 php-cgi
10709 www 16 0 359m 28m 17m R 96.8 0.4 0:11.34 php-cgi
10745 www 18 0 360m 24m 14m R 94.8 0.3 0:39.51 php-cgi
10707 www 18 0 360m 25m 14m S 77.4 0.3 0:33.48 php-cgi
10782 www 20 0 360m 26m 15m R 75.5 0.3 0:10.93 php-cgi
10708 www 25 0 360m 22m 12m R 69.7 0.3 0:45.16 php-cgi
10683 www 25 0 362m 28m 15m R 54.2 0.4 .65 php-cgi
10711 www 25 0 360m 25m 15m R 52.2 0.3 0:44.25 php-cgi
10688 www 25 0 359m 25m 15m R 38.7 0.3 0:10.44 php-cgi
10719 www 25 0 360m 26m 16m R 7.7 0.3 :40.59 php-cgi

找その中の一个CPU 100% の php-cgi 処理の PID、次のコマンドを使用して追跡します:

strace -p 10747

如果画面表示:

select(7, [6], [6], [], {15, 0 }) = 1 (出力 [6]、左 {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (タイムアウト)
select(7, [6], [6], [], {15, 0}) = 1 (出力 [6]、左 {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (タイムアウト)
select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0})
poll([{fd=6, events= POLLIN}], 1, 0) = 0 (タイムアウト)
select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (タイムアウト)
select(7, [6], [6], [], {15, 0}) = 1 (アウト[6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (タイムアウト)
select(7, [6], [6], [] 、{15, 0}) = 1 (出力 [6]、左 {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (タイムアウト)
select(7 , [6], [6], [], {15, 0}) = 1 (出力 [6]、左 {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (タイムアウト)
select(7, [6], [6], [], {15, 0}) = 1 (out [6], left {15, 0})
poll([{fd =6, events=POLLIN}], 1, 0) = 0 (タイムアウト)
select(7, [6], [6], [], {15, 0}) = 1 (out [6], left { 15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (タイムアウト)
select(7, [6], [6], [], {15, 0} ) = 1 (出力 [6]、左 {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (タイムアウト)

那么，就可确定是 file_get_contents( ) 結果として生じる問題は解決しました。

http://www.bkjia.com/PHPjc/363903.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/363903.html技術記事時々、Nginx、PHP-CGI(php-fpm) Web サービスの Linux サーバーを実行し、突然システムのダウンロードが上昇し、トップ コマンドを使用して、多くの php-cgi プロセスの CPU 使用率が 100% に近づきます。その後...