Apacheが倒れないようにするにはどうすればよいですか？
中程度のトラフィックで単一のMagentoeコマースサイトをホストしているサーバーのペアがあります（Google Analyticsから報告された1日あたり60kページビュー、サーバー自体で報告された約80kだと思います）。データベースサーバーは、まれに発生する一時的な中断を除けば、スムーズかつ迅速に実行されますが、Apacheサーバーは頻繁にフォールオーバーしています。
推奨されるPHPキャッシング（APC）を使用し、独自のキャッシュファイルを1.5ギガのtmpfsに保持するようにmagentoを設定しました（このtmpfsは定期的にかなりいっぱいになり、スクリプトがありますtmpfsが80％以上いっぱいになると、キャッシュファイルをクリアするために実行されます）。ほとんどの画像をAmazonクラウドフロントから提供しています。最近、nginxをApacheのリバースプロキシとして設定しました（nginxは静的ファイルも提供します）。Apacheをに構成しました。私の能力の限り-keepalivesとhostnamelookupsはオフであり、プリフォークは次のように構成されています。
<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にホストしているサイトを分割することだと思います。
だから、私の質問は次のとおりだと思います：
- サーバーの問題やボトルネックを見つけるために他に何ができますか？
- これを改善するためにサーバー構成に加えることができる明らかな変更はありますか？
- 負荷が特定のレベルを超えたときにApacheを再起動するように自動システムを設定することは良い考えですか？
- 上記から、サイトがサーバーを超えた可能性はどのくらいありますか？
編集：
私は何か奇妙なものを見つけました-/ var/pool/mail/rootは大きかった... 38ギガ。それは...不健康に聞こえます。それが問題でしょうか？
お気づきのように、MagentoとZendFrameworkはCPUをかなり使用します。 CPUの負荷を回避する最善の方法は、コンテンツが変更されるまで、コンテンツを1回だけレンダリングすることです。カタログのほとんどの部分はそれほど頻繁には変更されず、多くの場合、ページ上のショッピングカートブロックのみ、または「最も人気のあるアイテム」ブロックのみが動的な部分です。
Varnish キャッシュをApacheの前に置くことをお勧めします。これにより、LAMPスタックを大幅にオフロードできる高性能のページキャッシュが提供されます。私たちは最近、Varnishのおかげで、非常に一般公開されたWebサイトを生き延びました。私は、速度とCPU負荷の低さに真剣に感銘を受けました。ワニスは無料で、ページ全体をキャッシュするか、比較的静的な部分のみをキャッシュしてカートを動的に含めるのに十分な柔軟性があります。
ただし、ユーザーごとの動的コンテンツやCookieなどが多数あるため、VarnishはデフォルトのMagentoインストールではあまりキャッシュしません。「 PageCachepowered by Varnish 」などのMagentoモジュールは、Magentoを機能するように変更します。ワニスとよく合います。また、Magentoの設定に一致するVarnish構成ファイルも提供します。これら2つを組み合わせると、非常に効率的なセットアップが可能になります。これは商用モジュールですが、より強力なサーバーよりもはるかに手頃な価格です。
CDNまたはNginxにオフロードする部分は、役に立ちますが、実際の問題ではありません。 Apacheでさえ、かなりの数の静的リクエストを処理できます。何度も生成するのに手間がかかるもの、つまり動的な部分をキャッシュする必要があります。
私は通常、MaxRequestsPerChildを数千に設定します。通常は10,000に近くなります。
「推奨されるPHPキャッシング」）があると言いますが、APCはインストールされていますか？最後に、同時にWebサイトにアクセスするユーザーは何人いますか。Apache拡張統計がある場合、一度に実際に実行状態にあるApacheプロセスの数を確認できます。
1秒あたり800のAPCファイルヒットがあり、さらに200のユーザーキャッシュが大量にあります。それがデュアルコアまたはクアッドコアの場合でも、問題なく維持できると思います。データベースが本当に追いついているのであれば、少なくとも現時点では、より大きなマシンとより多くのCPUを取得することが最善の方法かもしれません。
私は同様のセットアップを実行しますが、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/マグネトワニス 。
私はテスト環境でのみテストしましたが、これまでのところ良好です。
セッションをデータベースに保存しますか、それともディスクに保存しますか（そうであれば、tmpfsに保存しますか）？
平均負荷は、デュアルコアVPSには完全に高すぎます。 8が最大である必要があります。
Magentoにmod_pagespeedとイベントMPMを使用して成功しました。イベントMPMの使用に切り替えて、mod_pagespeedをインストールすることをお勧めします。
イベントMPMの詳細： ApacheイベントMPMドキュメント
そしてmod_pagespeed： Googleコード：mod_pagespeed
上記の変更を行った後も引き続き負荷の問題が発生する場合は、別のより適切なVPSプランへの切り替えを検討することをお勧めします。
Alisterが示唆しているように、MaxRequestsPerChildの値400はとてつもなく低いです。
負荷の平均は非常に高いですが、1日あたり6万ページビューはそれほど多くのトラフィックではありません。
通常、リクエストを処理するプロセスはいくつありますか？
私はMagentoに精通していませんが、この設定に問題があるようです。より低い負荷レベルで大幅に高いスループットを得ることができると思います。
スティーブ・スーダーズの本のコピーを手に入れて読んでください。すべての送信HTMLコンテンツ（静的および動的）の圧縮を有効にします。そして、適切なキャッシュ構成があることを確認してください。 access_logファイルへの％Dのログ記録を開始し、データの分析/速度低下の切り分けのためのツールをいくつか構築します。 MySQLについても同様です。
Mysqltuner.plを試して、問題が発生するかどうかを確認してください。
VPSを使用すると、CPUを共有します。ホストに相談して、VPSを忙しくないハードウェアに移動するか、専用にすることをお勧めします。
共有CPUが原因で、アプリケーションは時間どおりに実行できず、キューに入れられ続け、処理される要求が高くなり、それに伴うオーバーヘッドも発生します。最終的には、Apache、php、またはmysqlが独自の制限を超えてしまい、問題が発生するという状況が発生します。
結論はです。 VPSは基本的に共有CPUです。ホストが同じCPUに配置しているVPSアカウントが多すぎる可能性があります。
割り当てられたCPUを最大限に活用したい場合は、可能であればVPSの少ないより良いサーバーを要求するか（面倒ですがホストを移動します）、専用にします。
また、Amazonを完全に選択し、クラウド下のすべてのサーバーをセットアップするために数回クリックするだけのロードバランサーを使用してnginxについて心配する必要はありません。
/ var/mail .../rootフォルダーは色相であり、通常はアプリケーションから送信される多くの電子メールを収集することを意味します。例：バグのあるphpスクリプトが電子メールを送信しようとしているか、すべてのcronジョブがcron実行のステータスと出力を電子メールで送信するように構成されています。メールの中を見て、ファイルの内容を確認できます。私はあなたがそれがどこから来ているのかを見つけることができるようにそのエラーメッセージを推測しています。
さらに情報が必要な場合はさらに追加しますが、情報も必要になる場合があります