SugarCRMをインストールしています。これはメモリの負荷が高く、これは別の問題です。その間、128Mを超えるメモリを使用しようとするページでは、Apache(mod_php)プロセスがセグメンテーション違反で停止します。
[notice] child pid 6852 exit signal Segmentation fault (11)
PHPメモリ制限を128Mに設定した場合、信号11を取得できません。通常のPHPエラーが表示され、これ以上割り当てられないことを通知しますメモリPHPメモリの制限を128Mを超えて-少しでも-に設定した場合-そのメモリに移動するプロセスは、セグメンテーション違反を引き起こし、ユーザーに対して白い画面/接続の切断を引き起こします。
私はAtomicリポジトリーを備えたCentOS 6.2サーバーでPHP 5.3.21を使用しています。これは実動サーバーであるため、コンパイラーが存在しないため、コアダンプを実行するためにApacheプロセスを再コンパイルしますありえない。
APC 3.1.13がインストールされていますが、一部のサイトではこれが必要です。私のSugarCRMサイトでは(私は信じています)無効になっています。
これを診断するために他にどのような詳細が必要かわかりませんか?ここで誰かが同じような何かに遭遇した場合、私が見ることができるいくつかの明白なことがあるといいのですが。メモリ使用量がそれを超えた場合にクラッシュを引き起こすその128Mについてはどうですか?
編集:
プロットは濃くなります。このテストスクリプトは、PHPプロセスが約256Mでメモリ不足になるまで、256Mをmemory_limitに設定して実行されます。セグメンテーション違反は発生せず、実行されて正常に終了します。
<?php phpinfo();
$array = array();
while (true) {
$array[] = str_pad('', 1024*512, '0');
echo " " . memory_get_usage();
}
したがって、SegarCRMが行うこと(プレーンなPHP/MySQLアプリケーション)が原因でセグメンテーション違反が発生しますが、memory_limitが128MBytesを超えて設定されており、その128MByteのしきい値を超えるページに到達した場合のみです。これは、絞り込むのが非常に難しいでしょう。 PHPコードまたはアプリケーション内のコードの1つの特定の行が原因であるか、またはアプリケーションがたまたま行う一連の一連の処理の結果であるか(ガベージコレクターをトリガーするものを実行するなど) PHPバグをトリガーするために、データベース接続が開いているオブジェクト、または私が想像できるようなあらゆる種類のこと)を片付け始めるか、設定を解除するかは不明です。
これがサーバーの問題であり、おそらくプログラミングの回避策であることが判明しても、私は驚かないでしょう。
編集2:
これで、セグメンテーション違反を簡単に再現できます。
<?php
function test1() {
static $instance = 0;
$instance += 1;
echo " $instance ";
test1();
}
test1();
このようなことを行うと、セグメンテーション違反が予想される場合があります。個人的には、それがPHP=でよりよく処理されることを望みますが、多分それはPHPのコースと同等でしょうか?memory_limitが128Mに設定されている限り、それはうまく処理されるようです。256Mに設定すると、代わりにフォルトがセグメント化されます。
アプリケーションの実行を順を追って追跡することにより、初期キャッシュファイルを書き込むときに再帰ループに入るようです(SugarCRMは大量のキャッシュを実行します)。追跡するのは難しいですが、エラー処理の欠如が原因であると考えています。ファイルを書き込んだ後、fopen()の結果をチェックせずに、ファイルが存在することを期待します。私たちはSELinuxを実行していますが、それが邪魔になっているかどうか疑問に思っています。他のアプリでも確かにそうです。PHPのis_writeable()は「ここにファイルを書き込むことができます」と言っていますが、そうするとSELinuxが起動しますanは、「あなたが書いている方法はありませんthatここにファイル」と書いています。 SugarCRMは最初の質問をチェックし、それが本当に成功したかどうかを常にチェックするわけではありません。
だから-私はこれが今プログラミングの問題と考えることができると思いますか?それはまだサーバーの問題であり、PHP私の頭ではお互いにうまくいっていませんが、SugarCRMでの適切なバグ修正はそれを回避するはずです。
これは私が持っている限り近く、おそらく私が今のところ得るところまでです:
SugarCRMはファイル書き込みコマンドを適切にエラーチェックしないため、ファイルが書き込まれていないことに気付かない場合があります。
SugarCRMは、初回実行時にランタイムファイルを構築するときに、多くのキャッシュファイルを書き込みます。
これらのキャッシュファイルを作成するときに、一部の不正な権限により、一部のファイルが正しく書き込まれませんでした。
不足しているファイルにより、SugarCRMは無限の再帰ループになり、キャッシュ書き込みメソッドはそれ自体を再帰的に呼び出します。
PHPのmemory_limitが128Mを超える値に設定されていると、プロセスがメモリ不足になったと報告されるのではなく、セグメンテーションエラーが発生します。 128M未満でPHPプロセスはよりきれいに強制終了されます。これはPHPバグ、またはプラグイン(APCではない)のバグであると考えられます。 128Mの値がどこから来るのか、私にはわかりません。
SugarCRMを再インストールし、すべてのファイルとディレクトリを777に設定することで修正しました。アクセス許可は、どこで失敗しているのかがわかるまで巻き戻す必要があります。 PHPへのチケットと同様に、SugarCRM(コミュニティ版)へのチケットは有用です(私は彼らが必然的に要求するコアダンプを提供できないと思うので、デッドエンド)。
ご提案ありがとうございます。これが他の人に役立つことを願っています。
APCを削除し、代替のeAcceleratorまたはXCacheのいずれかに置き換えます。これは、APCがなくなるとすぐに消えてしまった、実稼働環境でのこれに似た、何年にもわたる神秘的なクラッシュの原因でした。