PHP-CGI処理CPUとfile_get_contents関数の100％関係

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 構成ファイル内の次のパラメーターです。

The timeout (in seconds) for serving a single request after which the worker process will be terminated 
Should be used when 'max_execution_time' ini option does not stop script execution for some reason 
'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 つのリクエストしか処理できないことを意味し、WebServer の回避も困難になります。 "502不正なゲートウェイ"。

完全な解決策を達成するには、PHP プログラマーが file_get_contents("http://example.com/") を直接使用する習慣をなくすことができますが、それをわずかに変更し、タイムアウトを追加し、次のコードを使用します。メソッド HTTP GET リクエストを実装します。それが面倒な場合は、次のコードを自分で関数にカプセル化することもできます。

$ctx = stream_context_create(array(
'http' => array( 
       'timeout' => 1 //设置一个超时时间，单位为秒 
       ) 
   ) 
); 
file_get_contents("http://example.com/", 0, $ctx); 
?> 

もちろん、php-cgi プロセスの CPU が 100% に達する原因はこれだけではありません。では、それが file_get_contents() 関数によるものであるかどうかを判断するにはどうすればよいでしょうか?

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

トップ - 10:34:18 724 日、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
スワップ: 合計 8193108k、使用済み 50776k、空き 8142332k、キャッシュ済み 412088k

PID ユーザー PR NI VIRT RES SHR S %CPU %MEM TIME+
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 0:32.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 0:40.59 php-cgi

その中の 1 つの CPU 100% の php-cgi 処理の PID を次のコマンドで追跡します:

strace -p 10747

strace -p 10747

select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)

すると、問題の原因は file_get_contents() であると判断できます。