5

時々ハングする PHP Web アプリケーションがあります。ページに移動すると、最大実行数が 210 であっても、何時間もロードしようとしてそこに座っているだけです。これは、プロキシの背後で curl を使用してダウンロードするアプリケーションです。エラー報告はすべてに設定されていますが、ページが空白でハングしているため問題ありません。

ハングした PHP プロセスのデバッグで何も見つかりません。

4

5 に答える 5

2

最後に確認したところ、HTTP/IO 操作は php 時間外に発生するため、CURL が停止またはタイムアウトしている可能性があります。

そのIOなので、phpはシステムライブラリにスローしてから、「select」を呼び出して戻ってくるのを待ちます。

戻ってこない場合.. php コードはループしていないため、戻ってこないことさえわかりません。

于 2008-11-05T03:25:01.183 に答える
1

カールの問題であることにお金を賭けます。数年前、追加した特定のcurlオプションで同様の問題が発生し、スクリプトがハングすることがありました。問題が何であったかを正確に思い出せたらいいのにと思いますが、カールが間違ったライブラリにリンクしていたことが原因だったと思います。(編集)実際、私の場合はSSLライブラリであると確信しています.curlは古いバージョンのopensslを使用していました。

最初にすべての呼び出しを削除してcurl_setopt()から、それらを再度追加して、エラーを特定できるかどうかを確認することをお勧めします。コマンドラインで同等のcurlコマンドを実行すると、すぐにエラーが表示される場合があります

curlが使用していたopensslライブラリを更新して修正しました。

于 2008-11-05T04:09:00.750 に答える
1

舞台裏で何が起こっているかを確認するには、xdebug をインストールしてから、トリガーされたプロファイリングを有効にします (?XDEBUG_PROFILE=1)... kcachegrind/etc と互換性のあるファイルシステムにログを出力します....これを使用して確認できます実行がハングしている場所。

もちろん、それはカールの問題である可能性が最も高いです....

于 2008-11-05T05:56:10.190 に答える
0

Xdebugは素晴らしいアイデアです。それでも問題が解決しない場合は、ktrace、strace、またはtrussを介してWebサーバーを実行することもお勧めします。それはそれが何をするのか、そしてそれがどこにぶら下がっているのかを正確に示します。

一時的な接続の問題があるか、アプリケーションが依存している他の何かがブロックされているようです。

Apacheを使用する場合は、ApacheHTTPデバッグガイドを確認してください。このガイドは少し*nix中心ですが、どのWebサーバーにも適用できます。

Webサーバーのデバッグに加えて、プロキシが常に稼働していて応答性があり、ダウンロードソースが常に利用可能であるかどうかのチェックを追加することもお勧めします。これらのチェックは、 nagiosなどのツールまたはPingdomなどのサードパーティサービスを使用して追加できます。最後になりましたが、これは一時的なDNSの問題である可能性もあるため、IPを使用してプロキシとダウンロードソースに接続したり、DNSサービスの監視を追加したりできます。

HTH

于 2008-11-05T17:03:28.690 に答える
0

これはつまらないように聞こえますが、ページ要求の最初にファイルハンドルを開いてから、/ tmp/debug.txtへのfwriteを開始します。最後の値が書き込まれる場所を確認してから、その領域のファイルにさまざまな変数値をエコーし​​始めます。バイナリ検索の理論を使用して、fwriteをコードの解像度のより細かいセクションに分散します。

i.e.

$fh = fopen("/tmp/debug.txt", "w");

fwrite($fh, "made it to here 1 \n");

//some code

fwrite($fh, "made it to here 2 \n");

//more code

fwrite($fh, "made it to here 3 \n");
于 2008-11-05T18:02:43.143 に答える