無料 -h サーバー上と列 無料 ディスプレイにはほぼゼロが表示されます。しかし、アプリケーションは正常に動作し、メモリエラーも発生しません。これはよくある現象です。Linuxは未使用のRAMをキャッシュとして使用し、プロセスが必要としたときにその一部を解放します。
マシンに本当にメモリが不足しているかどうかを確認するには、まず そして、時間の経過に伴うスワップとメモリアクティビティ。単一の値 使用済み それだけでは不十分です。サービスを停止したり、RAMを追加したりする前に私が使用している方法は次のとおりです。
基本的なコマンドには管理者権限は必要ありません。
無料 -hオプション -h 読み取り可能な単位（例えば、MiBまたはGiB）を自動的に選択します。 私まず、以下の3つの列から始めましょう。
合計: 新しいプロセスがスワップを発生させることなく取得できるメモリの推定値。無料現時点で全く使用されていないページ。
利用可能 一般的には、 無料カーネルはキャッシュの一部と回復可能な構造を解放する方法を知っています。300 MiB のマシン 無料 しかし4 GiB RAMが不足しているわけではありません。
使用済み、共有済み、バッファ/キャッシュを、それらを合計せずに読み取る。
の列 無料 それらは、一緒に追加する必要のある独立した引き出しには対応していません。最近のバージョンの procps-ng では、 使用済み から計算されます 合計 そして 利用可能したがって、これはすべてのプロセスのRSSメモリの正確な合計ではありません。
共有主にメモリを使用するtmpfs;バッファコアバッファをカバーします。隠れた特に、ファイルキャッシュおよびリカバリ可能な構造を含む。バフ/キャッシュバッファとキャッシュを標準表示にグループ化します。
別れるには バッファ そして 隠れたワイドスクリーンディスプレイを使用する：
無料 -w -hこの視点はメモリ割り当てを理解するのに役立ちますが、診断結果を変えるものではありません。問題は、スワップなしでどれだけのメモリを回復できるか、そしてその余裕が永続的に減少するかどうかです。
LinuxがRAMをキャッシュで埋める理由
キャッシュをクリアしないでください ドロップキャッシュ 人工的に脊椎を高くする 無料
値の出典は以下で確認できます。 /proc/meminfo :
grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SReclaimable|SwapTotal|SwapFree):' /proc/meminfoメモリ利用可能 これはカーネルによって生成される推定値です。空きメモリと回復可能なキャッシュの一部を考慮に入れていますが、キャッシュ全体がすぐに回復できるとは想定していません。
単位を選択し、いくつかのサンプルを観察します。
複数の機器を比較する場合や、測定値を入力する場合は、固定単位を使用してください。 -m メビバイトを表示します。10進数単位の場合は、 - もし :
フリー -m
また、単一の孤立したキャプチャデータから結論を出すことは避けてください。 無料 2秒ごとに測定を繰り返し、5回測定した後に停止します。
フリー -h -s 2 -c 5どうか確認してください 利用可能 スワップ処理が進行し、処理完了後に状況が正常に戻る場合、継続的なパフォーマンス低下が発生します。バックアップやコンパイル中の短時間のパフォーマンス低下は、数時間にわたる継続的なパフォーマンス低下とは異なります。
RAMとスワップおよびvmstatの相互参照
ライン スワップ の 無料 これは占有状況を示すものであり、活動状況を示すものではありません。数ギガバイトの長期間使用されたデータがあっても、マシンがまだページ交換を行っているとは証明されません。アクティブな領域を一覧表示してから、観察してください。 そして それで と vmstat :
スワポン --表示
で vmstat瞬間的な活動を表す最初の行は無視してください。これは開始からの平均値を表しています。次の行はサンプルを示しています。 もし または それでに関連する 利用可能 メモリ使用量が少なく、動作が遅くなる場合は、メモリに実際に負荷がかかっていることを示しています。
へのガイド Linux でのスワップ 使用が正常な場合と、RAMなしでこれをクリアするとマシンがフリーズする可能性がある理由について説明します。
実際にメモリを消費しているプロセスを見つけてください。
指標が緊張状態を示している場合は、行動を起こす前にそのプロセスを特定してください。
ps -eo pid,user,comm,%mem,rss --sort=-rss | head
hトップRSS これはプロセスの常駐物理メモリを測定するものですが、一部のページは複数のプロセス間で共有される場合があります。そのため、すべてのRSS値を合計すると、実際の消費量を過大評価してしまう可能性があります。このリストを使用してリードを特定し、サービス、その構成、およびログを確認してください。
で hトップメモリ容量順にソートし、PIDとサービス名を取得してから、そのステータスを確認します。
systemctl status service-concerned --no-pager
journalctl -u サービス懸念 -n 100 --no-pagerリストの一番上にある最初のプロセスを強制終了しないでください。データベースはアプリケーションキャッシュとしてRAMを使用することが多く、その設定を尊重する場合があります。まず、RAMの使用量が安定していて、想定どおりであり、負荷が低下したときに解放されるかどうかを確認してください。
RAMが本当に不足していると判断すべきタイミング
記憶喪失の疑いは、複数の兆候が同時に現れた場合に信憑性が高まる。 利用可能 非常に低いままですが、 vmstat これは、繰り返しやり取りが発生し、応答時間が悪化し、最終的にカーネルがOOMキラーに信号を送ることを示しています。
journalctl -k -b | grep -Ei 'out of memory|oom-killer|killed process'
dmesg -T | grep -Ei 'メモリ不足|oom-killer|強制終了されたプロセス'無料マニュアルページ 列の計算を文書化する一方、 proc_meminfo(5) カーネルが提供するカウンタについて説明します。