Linuxのメモリ使用率確認方法は？コマンドも！（free：top：vmstatなど）

Linuxのメモリ使用率確認方法は？コマンドも！（free：top：vmstatなど）

Linuxサーバーの動作が重いとき、メモリ使用率を確認すると原因の切り分けにつながります。

ただし、表示された使用量だけを見て「メモリ不足」と判断すると、キャッシュやスワップの影響を見落とすことがあります。

free、top、vmstatなどのコマンドは、用途ごとに見える情報が異なります。

この記事では、Linuxのメモリ使用率を正しく確認する考え方と、代表的なコマンドの読み方をわかりやすく紹介します。

Linuxメモリ使用率の確認手順

それではまずLinuxのメモリ使用率を確認する基本手順について解説していきます。

空き容量だけで判断しない考え方

Linuxでは、利用されていないメモリをファイルキャッシュやバッファとして積極的に使います。

そのため、freeコマンドで空き容量が少なく見えても、すぐにメモリ不足とは限りません。

重要なのは、アプリケーションがすぐ利用できるメモリを示すavailableの値です。

availableが十分にあれば、キャッシュを解放して必要な処理に回せる余地があります。

一方でavailableが継続的に小さく、swapも増えている場合は、物理メモリ不足を疑う場面でしょう。

確認時に見るべき主要な項目

メモリ状況を確認する際は、総容量、使用量、利用可能量、キャッシュ、スワップ使用量を確認します。

総容量はサーバーに搭載された物理メモリの規模を表し、使用量はOSやアプリケーション、キャッシュを含んだ消費状況です。

利用可能量は新しい処理に割り当てやすいメモリの目安となります。

スワップはディスク領域を仮想メモリとして使う仕組みであり、使用量が増えるとディスクアクセスによる遅延が起こりやすくなります。

短時間だけスワップを使う場合と、常に増加し続ける場合では意味が異なります。

確認項目	見る意味	注意点
total	物理メモリ全体の容量	搭載量の基準
used	OSが使用中と扱う容量	キャッシュを含む場合がある
available	追加処理に使える目安	不足が続く場合に確認
buff cache	読み込み高速化用の領域	必要に応じて再利用される
swap used	仮想メモリの使用量	増加傾向と入出力を確認

障害調査につなげる確認順序

サーバーが遅いと感じたら、最初にfreeで全体像を把握し、次にtopで負荷の高いプロセスを探す流れが効率的です。

その後、vmstatでメモリ待ちやスワップ入出力が発生していないかを確認します。

特定のアプリケーションだけが急にメモリを使い始めた場合は、更新作業、アクセス急増、バッチ処理、メモリリークなどを時系列で照合します。

一度の数値だけではなく、数分から数時間の推移を見ることが原因の再現性を判断する鍵になります。

freeコマンドによるメモリ容量確認

続いてはfreeコマンドによるメモリ容量の確認を見ていきます。

freeコマンドの基本操作

freeは、Linuxのメモリとスワップの使用状況を短時間で表示できる代表的なコマンドです。

単位を見やすくするには、次のように-hオプションを付けます。

表示結果にはMem行とSwap行があり、Mem行は物理メモリ、Swap行はスワップ領域を示します。

hオプションでは、容量がMiBやGiBなど人が読みやすい単位で表示されるため、日常的な運用確認に便利です。

古い環境では表示列の名前や構成が一部異なることがあるため、available列の有無も確認するとよいでしょう。

available列とbuff cache列の読み方

freeのMem行にはtotal、used、free、shared、buff cache、availableなどが並びます。

このうちfreeは完全に未使用のメモリですが、Linuxでは未使用領域を減らしてキャッシュに使うため、freeだけが少ない状態は珍しくありません。

buff cacheはディスクから読み込んだデータなどを保持する領域で、再び同じファイルへアクセスする際の高速化に役立ちます。

最も実務で確認しやすい項目はavailableの残量です。

availableが数百MiB以下で推移し、メモリを多く使う処理が同時に動くなら、監視しきい値の見直しや増設を検討する余地があります。

列名	概要	確認の優先度
free	未使用の物理メモリ	単独判断はしない
used	使用中と計算される容量	推移を確認
buff cache	キャッシュとバッファの容量	増加自体は正常な場合が多い
available	新規処理に利用できる見込み容量	優先して確認

定期監視に活用する方法

freeは単発実行だけでなく、watchコマンドと組み合わせると変化を追いやすくなります。

この例では2秒ごとにfreeの結果を更新します。

バッチ処理の開始後やデプロイ直後に実行すると、availableが急減していないかを視覚的に確認できます。

ただし、watchの画面だけでは長期的な傾向は残りません。

運用環境では監視ツールでavailableとswap使用量を記録し、障害前後のグラフを確認できるようにしておくことが重要です。

topコマンドによるプロセス別使用量確認

続いてはtopコマンドによるプロセス別の使用量を確認していきます。

top画面に表示されるメモリ情報

topは、Linux上で動作しているプロセスをリアルタイムに表示するコマンドです。

画面上部にはメモリ全体の概要が表示され、下部にはCPU使用率やメモリ使用率の高いプロセスが一覧で出ます。

実行は次の一行です。

画面上部のMiB MemやKiB Memの行では、総メモリ、空きメモリ、使用中メモリ、キャッシュなどを確認できます。

表示単位は環境や設定によって変わりますが、項目の役割を理解すれば判断の流れは同じです。

プロセス一覧のRESは物理メモリ上に常駐している容量の目安であり、実際のメモリ消費を追う際に特に有用です。

メモリ使用率順への並べ替え

topの画面でShiftとMを入力すると、通常はメモリ使用率の高い順に並べ替えられます。

上位に表示されるプロセスのCOMMAND、PID、RES、MEMを確認すると、どのサービスがメモリを占有しているかを把握できます。

MEM列は物理メモリ全体に対する割合を表しますが、小さな割合でもプロセス数が多ければ合計で大きな負荷になります。

Java、Python、データベース、Webサーバー、コンテナランタイムなどは、設定やワークロードに応じて大きなメモリを使うことがあります。

一時的な上昇か、時間とともに増え続けるメモリリークの兆候かを区別することが必要です。

topで判断しにくいケース

topでは個々のプロセスの使用量を見つけやすい一方で、共有メモリの扱いには注意が必要です。

複数のプロセスが同じライブラリや共有領域を利用している場合、各プロセスのRESを単純に合計すると、実際の消費量より大きく見えることがあります。

また、コンテナ環境ではホスト側のtopだけでは、どのコンテナが原因か分かりにくい場合もあります。

そのようなときは、コンテナ管理機能の統計情報やcgroup単位の使用量も確認しましょう。

topは初動調査に強いコマンドであり、詳細な分析ではps、smem、systemdの情報などと併用すると精度が高まります。

vmstatコマンドによる負荷状況確認

続いてはvmstatコマンドによる負荷状況を確認していきます。

vmstatの基本表示

vmstatは、プロセス、メモリ、スワップ、入出力、CPUの状態をまとめて確認できるコマンドです。

メモリ使用率だけでなく、メモリ不足がシステム全体の待ち時間に影響しているかを見たいときに役立ちます。

たとえば、1秒ごとに5回表示するには次のように実行します。

最初の行は起動後の平均値を含むことがあるため、継続監視では2行目以降を中心に見ると状況をつかみやすくなります。

表示の列は多いものの、まずはsi、so、wa、r、bを確認するだけでも有用です。

siとsoから見るスワップ発生

vmstatのsiはスワップ領域からメモリへ読み込む量、soはメモリからスワップ領域へ書き出す量を示します。

これらが継続してゼロ以外なら、物理メモリが不足してページングが発生している可能性があります。

特にsoが連続して増え、siも発生している状況では、必要なデータをディスクへ退避しながら再読込しているかもしれません。

この状態はスラッシングにつながり、CPU使用率が高くないのに処理が遅く感じられる原因になります。

一時的なスワップ利用は必ずしも異常ではありませんが、通常運用中に続く場合は、負荷量とメモリ容量を見直す必要があります。

列名	意味	継続時の見方
r	実行待ちのプロセス数	CPU不足や負荷集中を確認
b	割り込み不可能な待機中の数	入出力待ちも疑う
si	スワップからの読込量	メモリ復帰が起きている目安
so	スワップへの書込量	メモリ圧迫の兆候
wa	入出力待ちのCPU時間	ストレージ遅延との関係を確認

CPUと入出力を併せた判断

メモリ問題では、CPU使用率だけを見ても原因が分からないことがあります。

vmstatでwaが高い場合、スワップやストレージアクセスが増えてCPUが処理待ちになっている可能性があります。

rが多いのにCPUのidleが少ないならCPU側の混雑が考えられ、siやsoが増えていればメモリ不足の影響も疑えます。

つまり、遅延の原因は一つとは限りません。

メモリ、CPU、ディスクの数値を同じ時間帯で比較すると、ボトルネックを誤認しにくくなります。

メモリ不足とスワップ使用量の判断基準

続いてはメモリ不足とスワップ使用量の判断基準を確認していきます。

スワップ使用量だけでは異常と決めない基準

Swap行のusedがゼロではないからといって、直ちに障害とは限りません。

Linuxは過去に使われたページをスワップへ退避し、その後も物理メモリに余裕ができたからといって必ずしも即座に戻しません。

そのため、スワップ使用量が少し残っていても、availableに余裕があり、siとsoがゼロなら、実害が出ていない場合があります。

問題になりやすいのは、スワップ使用量が増え続けること、ページインとページアウトが頻発すること、アプリケーションの応答が遅くなることです。

数値の絶対量ではなく、継続性と利用者影響を基準に判断しましょう。

OOM Killerが動作する前兆

Linuxではメモリが極端に不足すると、カーネルがOOM Killerを実行し、プロセスを強制終了させることがあります。

OOMはOut Of Memoryの略で、アプリケーションが突然停止する重大な事象につながります。

前兆として、availableの低下、スワップ入出力の継続、処理時間の悪化、ログ上のメモリ割り当て失敗などが見られることがあります。

ログ確認では、カーネルメッセージやsystemdの記録を参照し、どのプロセスが終了対象になったかを確認します。

メモリ上限のあるコンテナでは、ホスト全体に余裕があってもコンテナ単位の上限超過で終了する場合があるため注意が必要です。

改善策の優先順位

メモリ不足が確認されたときは、まず不要な常駐プロセスや重複したジョブがないかを確認します。

次に、アプリケーションのキャッシュ設定、ワーカープロセス数、Javaヒープ、データベースのバッファ設定などを見直します。

設定変更だけで改善しない場合は、処理の分散、実行時間の調整、メモリ増設、インスタンスサイズ変更を検討する流れになります。

短期的にスワップを無効化する対応は、根本的な容量不足を隠すことがあるため慎重さが必要です。

監視ではavailable、swap used、si、so、主要プロセスのRESを組み合わせ、予兆の段階で通知できる状態を目指すとよいでしょう。

Linuxメモリ使用率確認方法のまとめ

Linuxのメモリ使用率を確認するときは、free、top、vmstatを役割に応じて使い分けることが重要です。

freeではavailableを中心に全体の余裕を確認し、topではメモリを使うプロセスを特定します。

vmstatではsi、so、waを確認し、メモリ不足がスワップや入出力待ちに影響していないかを調べます。

freeの空き容量だけが少ない状態は、キャッシュを活用しているLinuxでは正常なこともあります。

一方でavailableの低下、スワップ使用量の増加、siとsoの継続、アプリケーション遅延が重なる場合は、早めの対応が必要でしょう。

単発の値だけではなく、処理実行前後や障害発生時の推移を記録することで、メモリ不足の原因をより正確に切り分けられます。