0

Cloud Linux を実行しているサーバーに移動されたサイトで、TinyMCE (MoxieCode) の ImageManager の古いバージョンを使用しています。

残念ながら、私たちのホスティングは、以前のサーバーには存在しなかった 1,048,576 KB の各アカウントのハード仮想メモリ制限があることを通知しませんでした.

これは多くのように聞こえますが、ImageManager は内部サーバー エラー 500 をランダムに生成し、サムネイルの 6 つに 1 つだけがランダムに選択されて正常にロードされます。

サーバーエラーログで、次のメッセージが非常に頻繁に繰り返されていることがわかります。これもさまざまなフォルダーのさまざまな index.php に対してランダムに発生します。ほとんどの場合、画像マネージャー/ストリームフォルダーだけでなく、言語フォルダー、js フォルダー、および rpc フォルダーにもあります。

メモリを割り当てられません: 子プロセスを作成できませんでした: /opt/suphp/sbin/suphp

驚いたことに、現在 ImageManager を更新している Web サイトの CPanel ページを更新すると、仮想メモリの使用量が 1,048,576 KB に達していることがわかります。(通常、それはその 10% をはるかに下回っています。)

テーマ、いくつかのスタイルシート、言語パック、および 6 つのサムネイルをロードするのに、なぜこの膨大な量のメモリが必要なのか、少し困惑しています。

特にphpinfoからわかるように、output_bufferingが0に設定されており、ob_startがImageManagerコードのどこにも呼び出されていません。

おそらく、サムネイルは mcith フォルダーから読み込まれるのではなく、毎回最初から作成されているのではないかと思いましたが、サムネイル ファイルの日付からわかるように、そうではありません。

実際、サムネイルを削除すると、完全にハングアップします (thumbnail.auto_generate が true に設定されています)。

確かに、他のサイトで使用していた最新の ImageManager (現在は MoxieManager と呼ばれています) にアップグレードすることはできますが、これは問題なく動作しますが、ユーザー インターフェイスとセッション認証が大幅に変更されているため、コーディングとコーディングの両方で多くの作業が必要になります。アップグレードを本当に望んでいないクライアントを再トレーニングします。

誰かがこの問題を解決する方法についてアイデアを持っているなら、それは大歓迎です。

4

1 に答える 1

0

できる最善の方法は、ImageManager のソース コードの各行の後に次のステートメントを使用することです。これは、メモリを消費する可能性があるように見えます

error_log("current memory usage: ".memory_get_usage()." on line: ".__LINE__);

バグのある行を見つけたら、代替案を探し始めることができます

于 2013-08-01T10:01:08.677 に答える