解決策 1:
top を実行中 バッチモードでメモリサイズを定期的に報告することは、事態が悪化したときに誰がメモリを使用しているかを確認するために使用できます。 sar を実行しています バッチ モードでは、メモリの使用状況と関連する I/O に関する適切な診断が得られるはずです。 munin を実行中 システムを監視すると、どのメモリが使用されているかについての詳細なグラフが表示されます。これは大いに役立つかもしれません。
limits.conf を使用して、プログラムの最大コア サイズを制限できます。適切に設定すると、メモリリークしているすべてのプログラムが強制終了されます。これは、pam_limits モジュールで機能します。 ulimits で制限を設定することもできます コマンド。
大量のメモリを使用する可能性のあるいくつかのプログラムを実行しています。あなたが見ることができるいくつかのものは含まれています。
apache2の下で実行されるプログラムが不十分なアプリケーション メモリリークする可能性があります。これが発生すると、メモリ サイズが増加するはずです。MaxRequestsPerChildを設定することで、一定回数使用した後に子をリサイクルするように apache2 を調整できます。 100かそこらに。これで問題が解決した場合は、リークを解決する必要があります。これを最初に見ます。- MySQL がデータをメモリにロードしようとする場合があります。メモリに大量のデータがある場合、スラッシングが発生する可能性がありますが、表示されているほど劇的ではありません。
tmpfsが大きい場合 ファイル システムがマウントされている場合、使用時にファイルを削除しないと、メモリ リークが発生する可能性があります。保存期間の長い大きなファイルも問題になる可能性があります。- ほぼ同じ時刻に問題が発生する場合は、スケジュールされたプログラムでメモリ リークが発生している可能性があります。
- 共有メモリを割り当てても、終了する前に解放しないプログラムがある場合、比較的目立たないメモリ リークが発生します。共有メモリーがメモリー内でロックされている場合、スワップが強制される場合があります。通常、使用可能な共有メモリの量は比較的限られています。
- liquidsoap+icecast バンドルは、メモリを使用するバッファリングの問題に遭遇する可能性があります。私はこの組み合わせを使用したことがないので、これがどのように表示されるかはわかりません。
通常のメモリ使用量:空きメモリはあまり必要ありません。システムが長時間稼働していて、空きメモリがたくさんある場合は、何か問題があります。ファイルを読み書きするたびに、ブロックはバッファ キャッシュに入ります。これにより、空きメモリが減少しますが、これは良いことです。システムは、他の場所でメモリを探すことなく、いくつかのプログラムを開始するのに十分な空き領域を保持します。多くのプログラムは高速で実行されるため、実行が停止するとメモリは空きプールに戻されます。
バッファ キャッシュにあるファイルを読み取る場合、ディスク アクセスは必要なく、読み取りはバッファ キャッシュから解決されます。書き込みも同様のメカニズムを使用します。システムにメモリが必要な場合、バッファ キャッシュは最初に使用される場所の 1 つです。ほとんどのバッファはすぐに解放できます。
メモリ リークがある場合は、空きメモリとバッファの両方が縮小し始めます。リークしたメモリは最終的にスワップ領域に移動する必要があるため、これはまだ深刻な問題ではありません。システムは、スワップ領域がいっぱいになるまで問題なく動作し、残りの空き領域をプログラムが起動できなくなるまで引き下げます。通常、少量のスワップ領域が使用されることがあります。
解決策 2:
このコマンドを使用して、RAM 使用量に関する上位 10 個のアプリケーションを表示できます:
ps -A --sort -rss -o comm,pmem | head -n 11
多くのサブプロセスが生成されている場合、このコマンドが役立つことがあります:
ps auxf
このようにして、どのプロセスが一緒に属しているかを確認できます。
解決策 3:
アプリケーションに関して、そのメモリを実際に使用しているものはありません。
プログラムの使用に関して実際のメモリ使用量を把握するには、ページ キャッシュを表す「キャッシュされた」値を差し引く必要があります。
基本的に、これは適切なメモリ管理であり、理想的にはこれが必要です。
詳細については、次のリンクを参照してください:http://www.linuxatemyram.com/