Apacheが転倒しないようにするにはどうすればよいですか？

中程度のトラフィックを持つ単一のMagento eコマースサイトをホストしているサーバーのペアがあります（Googleアナリティクスから報告された1日あたり6万ページビュー、サーバー自体については約8万レポート報告されています）。データベースサーバーは、まれに時折発生する問題を除いて、スムーズかつ迅速に実行されますが、Apacheサーバーは時々故障しています。

推奨のPHPキャッシング（APC）を使用するようにmagentoを設定し、1.5ギガのtmpfsに独自のキャッシュファイルを保持しています（このtmpfsは定期的にかなりいっぱいになり、tmpfsが実行されたときにキャッシュファイルをクリアするスクリプトを実行しています） 80％以上フル）。アマゾンクラウドフロントからほとんどの画像を提供します。私は最近、nginxをapacheのリバースプロキシとして設定しました（nginxは静的ファイルも提供します）。私はできる限りApacheを構成しました-キープアライブとホスト名検索はオフで、プリフォークは次のように構成されています。

<IfModule prefork.c>
    StartServers      50
    MinSpareServers   50
    MaxSpareServers  100
    ServerLimit  512
    MaxClients   256
    MaxRequestsPerChild 400
</IfModule>

.htaccessファイルをオフにしていません。アクセスログはオンになっています。オフにできるモジュールがいくつかあることは知っています。これら3つの変更のどれがどんな影響を与えるかはわかりません。

Apacheサーバーは、6ギガのRAMを備えたVPSです。執筆時点でサーバーはレポートしていますがload average: 17.77, 18.27, 49.76、約2ギガのRAMが解放されています。ひどい状態になると、負荷は120以上になり、そこに留まります。Apacheを再起動すると、サイトが復旧し、負荷が低下します。

vmstatは（サーバーが上記の負荷を報告している間）、CPUアイドル値が0から70の間で変動していることを示していると思います。iostatは0から0.2％のiowait値を示しています。

少し行き詰まっています。問題は、実行中のコードとユーザー数の組み合わせの結果としてCPUが過負荷になることであると私がほとんど知りません。しかし、私はそれが問題であることを確認するのに十分な経験がありません。それが問題である場合、解決策は、コードを改善するか、ロードバランサーを使用して2つのVPSでホストしているサイトを分割することです。

だから、私の質問は次のとおりだと思います：

1. サーバー上の問題やボトルネックを見つけるために他に何ができますか？
2. これを改善するためにサーバー構成に加えることができる明らかな変更はありますか？
3. 負荷が特定のレベルを超えたときにapacheを再起動するように自動システムを設定することは良い考えですか？
4. 上記から、サイトがサーバーを超えている可能性はどのくらいありますか？

編集：

私は変なものを見つけました-/ var / spool / mail / rootは大きいです... 38ギグ。それは聞こえます...不健康です。それが問題でしょうか？

お気づきのとおり、MagentoとZend FrameworkはCPUをかなり消費します。CPU負荷を回避する最善の方法は、単純ですが、コンテンツが変更されるまで、一度だけコンテンツをレンダリングすることです。カタログのほとんどの部分はそれほど頻繁に変更されず、多くの場合、ページ上のショッピングカートブロックのみ、または「最も人気のあるアイテム」ブロックのみが動的な部分です。

Apacheの前にVarnishキャッシュを置くことをお勧めします。これにより、LAMPスタックの負荷を大幅に軽減できる高パフォーマンスのページキャッシュが得られます。Varnishのおかげで、私たちは最近、非常に一般的なWebサイトの立ち上げを切り抜けましたが、速度とCPU負荷の低さには非常に感銘を受けました。Varnishは無料で、ページ全体をキャッシュしたり、比較的静的な部分だけをキャッシュしてカートを動的に含めたりするのに十分な柔軟性があります。

ユーザごとの動的なコンテンツ、クッキー、多くのがありますので、ワニスは、デフォルトMagentoのインストールに多くのキャッシュしませんなどA Magentoのモジュール等「などのワニスによって供給ページキャッシュニスでうまく動作するように修正Magentoの」。また、Magentoのセットアップと一致するVarnish構成ファイルも提供します。これら2つを組み合わせると、非常に効率的なセットアップが可能になります。これは商用モジュールですが、より強力なサーバーよりもはるかに手頃な価格です。

CDNまたはNginxへのオフロードの部分は、実際の問題ではありませんが、役立ちます。Apacheでも、かなりの数の静的リクエストを処理できます。動的なパーツなど、何度も生成するのに必要なものをキャッシュする必要があります。

私は通常、MaxRequestsPerChildを数千に設定します-通常、10,000に近くなります。

「推奨されるPHPキャッシング」があるとおっしゃっていますが、APCはインストールされていますか？最後に、何人のユーザーが同時にWebサイトにアクセスしていると思いますか。Apache拡張統計がある場合、一度に実際に実行状態にあるApacheプロセスの数を確認できます。

1秒あたり800のAPCファイルヒット、そしてさらに200のユーザーキャッシュが大量にあります。それがデュアルコアまたはクアッドコアである場合、私はそれが大丈夫であり続けると期待します。データベースが本当のペースで稼働している場合は、少なくとも今のところ、より大きなマシン（およびより多くのCPU）を入手することが最良の方法です。

デュアルコアVPSの平均負荷が高すぎます。8が最大です。

Magentoでmod_pagespeedとイベントMPMを使用して、うまくいきました。イベントMPMを使用するように切り替え、mod_pagespeedをインストールすることをお勧めします。

イベントMPMに関する詳細情報：ApacheイベントMPMドキュメント

そしてmod_pagespeed：Googleコード：mod_pagespeed

上記の変更を行っても負荷の問題が続く場合は、別のより良いVPSプランへの切り替えを検討してください。

アリスターが示唆するように、400のMaxRequestsPerChild値は、とてつもなく低い値です。

負荷平均は非常に高いですが、1日あたりのページビューは60kで、トラフィックはそれほど多くありません。

通常、リクエストを処理するプロセスはいくつありますか？

私はMagentoに詳しくありませんが、この設定に問題があるようです。低負荷レベルで大幅に高いスループットが得られると思います。

Steve Soudersの本を手に取り、読んでください。すべての発信HTMLコンテンツ（静的および動的）の圧縮を有効にします。そして、適切なキャッシング構成があることを確認してください。％Dをaccess_logファイルに記録し始め、データを分析したり、速度を分離したりするためのツールをいくつかビルドします。MySQLでも同様です。

mysqltuner.plを試して、問題があるかどうかを確認します。

私は同様の設定を実行しますが、nginx / php-fpm / apc（opcodeおよびfast_backend / memcached（slow_backend）を使用します。おそらく、magentoが異常に大きいか、コードが不適切なため、phpが最大のリソース問題であることがわかります。正確にリソースを食べているものを見てください、私の場合のようにそれはphpですか？

Martijn Heemelsが書いたものに加えて、あなたが試すことができるオープンソースのニスモジュールがあります。http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/およびhttps://github.com/madalinoprea/magneto-varnishを確認してください。
私はそれをテスト環境でテストしただけで、今のところとても良いです。

セッションをデータベースに保存しますか、それともディスクに保存しますか（保存している場合は、tmpfsに保存しますか）？

VPSを使用すると、CPUを共有します。ホストと話し合って、VPSをよりビジーでないハードウェアに移動するか、専用にすることをお勧めします。

共有CPUが原因で、アプリケーションは時間どおりに実行できず、キューに追加されて処理されるより高い要求と、それに伴うオーバーヘッドが蓄積されます。最終的には、Apache、php、またはmysqlが独自の制限を超えてしまい、それらが問題を引き起こす状態が発生します。

ボトムラインです。VPSは基本的に共有CPUです。ホストが同じCPUに割り当てるVPSアカウントが多すぎる可能性があります。

割り当てられたCPUを最大限に活用したい場合は、可能であればVPSの少ないより良いサーバーを要求するか（ホストを移動するのは面倒です）、専用にするかしてください。

また、Amazonを完全に選択し、ロードバランサーを使用してnginxを心配する必要はありません。ロードバランサーを数回クリックするだけで、クラウド下のすべてのサーバーをセットアップできます。

/var/mail.../rootフォルダーは、通常、アプリケーションから送信される多数のメールを収集することを意味します。たとえば、バグの多いphpスクリプトがメールを送信しようとしている、またはすべてのcronジョブがcronの実行と出力のステータスをメールで送信するように構成されている場合などです。メールの内部を見て、ファイルの内容を確認できます。エラーメッセージを推測しているので、どこから来たのかを見つけることができます。

さらに情報が必要な場合はさらに追加します。情報も必要になる場合があります