サーバーのメモリ不足の原因を突き止めることができない

Question 1

同時接続ユーザーは通常10人程度で、20人を超えることはありません。

...しかし、スクリーンショットには 23 個のアクティブな MySQL セッションが表示されており、Web サーバーは 256 個を許可するように構成されています。

安価なホスティングでのスワップはアンチパターンです。マシンがスワップ状態になり始めると、リクエストが Apache にバックアップされ始める間、マシンはスワップファイルの読み取りと書き込みにすべての時間を費やすことになります。

Wordpress については良いことは何も言えません。

スクリーンショットから、PHP 用の CLI SAPI が動作していることがわかります。そして、oom killer は、PHP がシステム上でメモリを最も消費する原因であると判断しました。これは、mod_php や php-fpm ではなく、CGI PHP を実行していることを示しています。そうであれば、ホストのメモリが不足する問題だけでなく、ページがものすごく遅い理由も解決したことになります。

キープアライブオフ

これは本当に役に立ちません。ブラウザ側のエクスペリエンスが確実に悪化します。キャッシュとCDNが設定されている場合でも、タイムアウトを500ms未満に設定する必要があります。その通り右。

もちろん、これは Apache 設定のすべてではありません。他の多くの設定も重要です。圧縮が有効になっていることを確認することは重要です (データを圧縮する方が TCP トラフィックを処理するよりも CPU 時間が少なくて済み、データ転送を待つ大きな Apache プロセスがメモリ内に滞留する必要がなくなります)。

何が起こったかについて多くの情報を提供してくれたにもかかわらず後oomキラーを検知するには、その前に何が起こっているかを確認する必要があります。そして、その情報はデフォルトでは取得されません。最低限必要なのは、メモリ使用量とApacheインスタンス数。

Answer

同時接続ユーザーは通常10人程度で、20人を超えることはありません。

...しかし、スクリーンショットには 23 個のアクティブな MySQL セッションが表示されており、Web サーバーは 256 個を許可するように構成されています。

安価なホスティングでのスワップはアンチパターンです。マシンがスワップ状態になり始めると、リクエストが Apache にバックアップされ始める間、マシンはスワップファイルの読み取りと書き込みにすべての時間を費やすことになります。

Wordpress については良いことは何も言えません。

スクリーンショットから、PHP 用の CLI SAPI が動作していることがわかります。そして、oom killer は、PHP がシステム上でメモリを最も消費する原因であると判断しました。これは、mod_php や php-fpm ではなく、CGI PHP を実行していることを示しています。そうであれば、ホストのメモリが不足する問題だけでなく、ページがものすごく遅い理由も解決したことになります。

キープアライブオフ

これは本当に役に立ちません。ブラウザ側のエクスペリエンスが確実に悪化します。キャッシュとCDNが設定されている場合でも、タイムアウトを500ms未満に設定する必要があります。その通り右。

もちろん、これは Apache 設定のすべてではありません。他の多くの設定も重要です。圧縮が有効になっていることを確認することは重要です (データを圧縮する方が TCP トラフィックを処理するよりも CPU 時間が少なくて済み、データ転送を待つ大きな Apache プロセスがメモリ内に滞留する必要がなくなります)。

何が起こったかについて多くの情報を提供してくれたにもかかわらず後oomキラーを検知するには、その前に何が起こっているかを確認する必要があります。そして、その情報はデフォルトでは取得されません。最低限必要なのは、メモリ使用量とApacheインスタンス数。

Question 2

何らかの理由で、maxclients パラメータに達しています。

サーバーがダウンしたときの 1 秒あたりのリクエスト数について、さらに詳しい情報はありますか? スワップが完全にいっぱいになってサーバーがクラッシュしているようです。どのコンポーネントがどのくらいのメモリを使用しているかについて、何か情報はありますか?

Answer

何らかの理由で、maxclients パラメータに達しています。

サーバーがダウンしたときの 1 秒あたりのリクエスト数について、さらに詳しい情報はありますか? スワップが完全にいっぱいになってサーバーがクラッシュしているようです。どのコンポーネントがどのくらいのメモリを使用しているかについて、何か情報はありますか?

Question 3

サーバーのメモリ使用量を確認する簡単な方法は、というツールをインストールすることですhtop。htop は、プロセスごとにサーバーの重要情報を提供します。メモリを確認する場合は、htop をロードして、Mメモリで並べ替える (または>カテゴリを選択する) ことができます。

どのアプリケーションが最も多くのメモリを使用しているかがわかれば (Max クライアント数に達し、同時に OOM キラーがトリガーされたことを考えると、Apache だと思います)、それを微調整できます。ただし、容量の問題があることは間違いありません。ログに示されているように、Apache の最大クライアント数に達していますが、RAM が不明なため、現時点では安全に増やすことはできません。これは顧客に影響を与えています。適切な監視ツールを入手して、常に監視してください。

また、クラッシュ時の Apache アクセスログをチェックしても問題ないかもしれません。通常、同時ユーザーは 20 人を超えないとおっしゃっていますが、Apache プロセスの最大制限である 50 に達しています。これが正当なトラフィックだった場合、サーバーをより適切に調整し、リソースをアップグレードする必要があります。そうでない場合は、不要なものをフィルタリングする方法を探してみてください (言うのは簡単ですが、実行するのは難しいです)。

Answer

サーバーのメモリ使用量を確認する簡単な方法は、というツールをインストールすることですhtop。htop は、プロセスごとにサーバーの重要情報を提供します。メモリを確認する場合は、htop をロードして、Mメモリで並べ替える (または>カテゴリを選択する) ことができます。

どのアプリケーションが最も多くのメモリを使用しているかがわかれば (Max クライアント数に達し、同時に OOM キラーがトリガーされたことを考えると、Apache だと思います)、それを微調整できます。ただし、容量の問題があることは間違いありません。ログに示されているように、Apache の最大クライアント数に達していますが、RAM が不明なため、現時点では安全に増やすことはできません。これは顧客に影響を与えています。適切な監視ツールを入手して、常に監視してください。

また、クラッシュ時の Apache アクセスログをチェックしても問題ないかもしれません。通常、同時ユーザーは 20 人を超えないとおっしゃっていますが、Apache プロセスの最大制限である 50 に達しています。これが正当なトラフィックだった場合、サーバーをより適切に調整し、リソースをアップグレードする必要があります。そうでない場合は、不要なものをフィルタリングする方法を探してみてください (言うのは簡単ですが、実行するのは難しいです)。

サーバーのメモリ不足の原因を突き止めることができない

答え1

答え2

答え3

関連情報