電子メールの送信後に中程度のトラフィックでラックスペース WordPress サーバーがダウンするという問題が発生しています。
サーバーの仕様は次のとおりです。
CPU 2 vCPUs
RAM 2 GB
System Disk 80 GB
Network 240 Mb / s
Disk I/O Good
ランニング：
Centos 7.0
Wordpress 4.3.1
Httpd 2.4.6
PHP 5.4.11
MariaDB 5.5.41
私の知る限り、インストールはすべてかなり標準的で、データベースもかなり標準的で、インデックス化されており、かなり小さいです。また、WordPress オブジェクト キャッシュも使用しています。
New Relic によると、通常のトラフィックでは、サイトは約 80% の時間を PHP で、15% の時間を Web 外部で、わずかな割合だけをデータベースで費やしています。平均的な標準ページ アプリ時間は約 800 ミリ秒で、これは遅いように思えます。
1 分間に 250 の接続の負荷テストを実行すると、接続にかかる時間が徐々に長くなり、約 30 秒後にタイムアウトし始め、サーバーが応答しなくなります (トラフィックが減っても)。再度アクティブにするには、ハードリブートが必要です。
putty を使用して接続できず、ホームページはタイムアウトと、恐ろしい「データベース接続確立エラー」の表示を交互に繰り返します。
最新のテストでラックスペース監視エージェントを使用すると、CPU が死の直前に最大 100% に達し、メモリ使用量が約 1.6 GB でピークに達し、空き容量が約 100 MB に低下していることがわかります。約 2 GB のスワップ メモリ (合計 4 GB) も使用されているようです。標準的な使用量は、CPU が約 15%、メモリが 800 MB、スワップが 400 MB のようです。
私たちの Apache 設定では、Timeout、KeepAlive、MaxKeepAliveRequests、KeepAliveTimeout のいずれも設定されていません ( /etcdo にファイルはありません)。そのため、デフォルト値が使用されていると推測します。
mariadb の設定を確認しました:
innodb_buffer_pool_size = 1400M
max_user_connections = 0
それが原因ではないようです。
performance_schema もオンにしましたが、何を探しているのかよくわかりません。DB に問題があるかどうかもわかりません。
インスタンスをアップグレードしたい気持ちはありますが、単に速度が低下するのではなく、ボトルネックがどこにあるのか、サーバーがダウンする原因は何か、をより明確に把握したいのです。
どこから始めればよいか、何かアイデアはありますか? 可能な調整方法や情報がたくさんありそうです。
答え1
いかなるイベントでも綿密な監視が重要です。ご覧のとおり、真実が明らかになりました。
最新のテストでラックスペース監視エージェントを使用すると、CPU が死の直前に最大 100% に達し、メモリ使用量が約 1.6 GB でピークに達し、空き容量が約 100 MB に低下していることがわかります。約 2 GB のスワップ メモリ (合計 4 GB) も使用されているようです。標準的な使用量は、CPU が約 15%、メモリが 800 MB、スワップが 400 MB のようです。
PHP は CPU をかなり集中的に使用することで知られています。使用可能な CPU のすべてと、使用可能な RAM のほぼすべてを使用しています。
まず、オペコードキャッシュ（例：Zend OPcache）やファイルキャッシュ（例：W3 Total Cache WordPressプラグイン）などの対策を講じる必要があります。それでも問題が解決しない場合は十分インスタンスをアップグレードする時が来ました。
答え2
おそらく、一度に実行しているプロセスが多すぎて、メモリが不足し、スワップが乱立しているのでしょう。他の何かがロックしている可能性もありますが、まずはこれに対処してから、状況を確認してください。
mod_php を使用しているのか、それとも php-fpm のようなものを使用しているのかはわかりません。後者の方が負荷をうまく処理しますが、どちらの場合でも、メモリ容量を超える数の PHP プロセスを実行しないでください。5 個または 10 個を超えるプロセスを実行してもパフォーマンス上のメリットは得られないでしょうが、特に mod_php のデフォルトの実行では、メモリ容量を超えるプロセスが実行されます。また、30 リクエストごとにプロセスをリサイクルしてください。データベースと OS に 1 GB 割り当てると、残りの GB では 10 個の WordPress プロセスを処理できない可能性があります。メモリ使用量を確認し、少し余裕を持って計算してください。通常、スワップを使用する必要はありません。
キープアライブ設定を確認してください。Apache では、おそらくこれをオフにするか、1 秒に設定するのが最善です。Nginx はキープアライブをはるかにうまく処理します。実際、これが WordPress などの PHP アプリケーションで nginx のパフォーマンスが向上する唯一の重要な理由です (ただし、設定があまり快適ではなくなります)。これは、テストではおそらく要因になりませんが、実際のブラウザーでは重要です。
CPU 使用率が 100% というのは驚きです。top を使用して、何が CPU を使用しているか確認してください。また、100% は多くの場合、1 つのコアが 100% 使用されていることを意味することにも注意してください。1 つの cron ジョブが起動しているだけかもしれませんが、WordPress では、これは通常「cron」ではなく、Web リクエストの処理中にジョブが追加で実行されます。オペコード キャッシュが不足していることも、CPU 使用率が高くなる原因となっている可能性があります。