「freeコマンドの数字とカーネルの内部情報が食い違っている気がする」
そんな経験はありませんか。実は、Linuxが動作中にリアルタイムで公開しているシステム情報の大半は、/proc というディレクトリに集約されています。
この記事では、/procファイルシステム の仕組みと、現場でよく参照する主要ファイル（meminfo・cpuinfo・loadavg・net・status）の読み方を実機出力とともに解説します。コマンドの裏側にある数字の意味を掴めるようになると、障害調査の精度が格段に上がります。
この記事のポイント
・ /proc は「カーネルが動的に生成する仮想ファイルシステム」でディスクに書かれていない
・ /proc/meminfo・cpuinfo・loadavg は free/top/uptime の生データ源
・ /proc/[PID]/status でプロセス単位のメモリ・スレッド数を確認できる
・ /proc/net 配下でソケット・ルーティング情報をテキストで直読みできる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
/procファイルシステムとは何か
/proc は「プロセスファイルシステム（procfs）」と呼ばれる仮想ファイルシステムです。ディスクには一切書かれておらず、カーネルが読み取り要求を受けた瞬間にメモリ上のデータを動的に生成してテキストとして返します。マウントポイントを確認すると次のように表示されます。
# マウント状態の確認 $ mount | grep proc proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
重要な特徴をまとめておきます。
・リアルタイム性：catするたびにその瞬間のカーネル内部状態が返ってくる
・書き込み可能なファイルがある：/proc/sys 配下のファイルはsysctlを通じて書き込みができ、カーネルパラメータを変更できる
・ディスク使用量ゼロ：df -h で /proc が表示されても使用量は0
・RHEL系・Debian系問わず共通：カーネルが提供する機能のため、ディストリビューションに依存しない
実行環境: RHEL 9.4 / Ubuntu 24.04 LTSで動作確認済み。
/proc/meminfo でメモリ情報を読む
1. 基本的な見方
freeコマンドの数字が「どこから来ているか」を知りたいときは /proc/meminfo を直接見ます。$ cat /proc/meminfo MemTotal: 16238772 kB MemFree: 423104 kB MemAvailable: 8921640 kB Buffers: 312448 kB Cached: 7418828 kB SwapCached: 0 kB Active: 5238912 kB Inactive: 8102184 kB SwapTotal: 2097148 kB SwapFree: 2097148 kB Dirty: 2048 kB Writeback: 0 kB AnonPages: 5615672 kB Mapped: 821936 kB Shmem: 317560 kB Slab: 658432 kB SReclaimable: 524288 kB SUnreclaim: 134144 kB HugePages_Total: 0 HugePages_Free: 0
2. 現場で特に注目するフィールド
・MemAvailable：スワップなしで実際に割り当て可能なメモリ量。free コマンドの「available」列と一致する。MemFreeよりも実態に近い指標・SwapFree / SwapTotal：スワップ消費が増えている場合はメモリ不足の予兆。双方を見て残量を確認する
・Dirty：まだディスクに書き込まれていないキャッシュ量。大量になるとI/O負荷スパイクの原因になる
・Slab / SReclaimable：カーネル内部のメモリ使用量。SReclaimable はページキャッシュに近く、メモリ不足時はカーネルが回収できる
特定フィールドだけ取り出したい場合は grep が便利です。
# MemAvailable だけ確認 $ grep MemAvailable /proc/meminfo MemAvailable: 8921640 kB # スワップ関連をまとめて確認 $ grep Swap /proc/meminfo SwapCached: 0 kB SwapTotal: 2097148 kB SwapFree: 2097148 kB
/proc/cpuinfo でCPU情報を読む
1. 出力の構造
/proc/cpuinfo はCPUコアごとにブロックが区切られて出力されます。論理CPU（スレッド）数だけブロックが繰り返されます。$ cat /proc/cpuinfo | head -30 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 165 model name : Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz stepping : 5 microcode : 0xf6 cpu MHz : 2900.000 cache size : 16384 KB physical id : 0 siblings : 16 core id : 0 cpu cores : 8 apicid : 0 fpu : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep ...
2. 論理CPU数と物理コア数を確認する
ハイパースレッディングの有無を含めてCPU構成を把握したい場合は以下の手順で確認します。# 論理CPU数（processorブロックの数） $ grep -c processor /proc/cpuinfo 16 # 物理コア数（cpu cores の合計 ÷ 物理CPUソケット数） $ grep "cpu cores" /proc/cpuinfo | sort -u cpu cores : 8 # 物理CPU（ソケット）数 $ grep "physical id" /proc/cpuinfo | sort -u | wc -l 1 # CPUモデル名を確認 $ grep "model name" /proc/cpuinfo | sort -u model name : Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz
なお lscpu コマンドも同じ /proc/cpuinfo を解析して見やすく整形した結果を表示します。生データが必要な場合（自動化スクリプト、CI/CD等）は /proc/cpuinfo を直接参照するとパース処理を自前で書けます。
/proc/loadavg でロードアベレージを読む
1. ファイルの内容
$ cat /proc/loadavg 2.38 1.92 1.45 3/524 28741
2. 各フィールドの意味
・2.38：直近1分間の平均ロードアベレージ・1.92：直近5分間の平均ロードアベレージ
・1.45：直近15分間の平均ロードアベレージ
・3/524：「現在実行中のプロセス数 / 全プロセス数」。3個のプロセスが実際にCPUを使っており、合計524プロセスが存在する
・28741：最後に生成されたプロセス・スレッドのPID
uptime や topコマンドのload average値は /proc/loadavg から取得しています。シェルスクリプトで閾値監視をする際はこのファイルを直接読む方がコマンド出力のパースより安定します。
# 1分ロードアベレージだけ取り出す $ awk '{print $1}' /proc/loadavg 2.38 # 閾値（例:4.0）超えで警告を出すスクリプト例 $ LOAD=$(awk '{print $1}' /proc/loadavg) $ echo "$LOAD > 4.0" | bc -l 0
/proc/[PID]/status でプロセス情報を詳しく読む
1. 特定プロセスの詳細確認
/proc 配下には数字のディレクトリが並んでいます。これが各プロセスのPIDに対応したディレクトリです。その中の status ファイルで、そのプロセスの詳細な状態を確認できます。# sshd の PID を確認 $ pgrep sshd 1234 # そのプロセスの status を確認 $ cat /proc/1234/status Name: sshd Umask: 0022 State: S (sleeping) Tgid: 1234 Ngid: 0 Pid: 1234 PPid: 1 Threads: 1 VmPeak: 12348 kB VmSize: 12144 kB VmRSS: 5120 kB VmSwap: 0 kB
2. 現場で特に確認するフィールド
・State：プロセスの状態。S(sleeping)/R(running)/D(disk wait)/Z(zombie)の違いを把握することが障害調査の第一歩・Threads：そのプロセスが持つスレッド数。急激に増えている場合はスレッドリーク疑い
・VmRSS：実際に物理メモリに載っているサイズ（Resident Set Size）。プロセスの実メモリ消費を表す
・VmSwap：スワップに追い出されているサイズ。0でない場合はメモリ不足のサイン
全プロセスのメモリ消費をランキング表示したい場合は以下のワンライナーが使えます。
# 全プロセスの VmRSS 上位10件を表示 $ for pid in /proc/[0-9]*/status; do awk '/^Name|^VmRSS/{printf $2" "} /VmRSS/{print ""}' "$pid" done 2>/dev/null | sort -k2 -rn | head -10 httpd 524288 kB mysqld 204800 kB java 131072 kB
/proc/net 配下でネットワーク情報を確認する
1. 主要なファイル一覧
/proc/net 配下にはネットワーク関連の情報がテキスト形式で格納されています。$ ls /proc/net/ arp dev fib_trie if_inet6 ipv6_route route snmp sockstat tcp tcp6 udp udp6
2. /proc/net/sockstat でソケットの統計を確認する
$ cat /proc/net/sockstat sockets: used 432 TCP: inuse 24 orphan 0 tw 4 alloc 28 mem 3 UDP: inuse 12 mem 5 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0
・tw（TIME_WAIT）：TIME_WAIT状態のソケット数。短時間の接続を大量に繰り返すと急増する
・orphan：アプリケーションから切り離されたが、まだカーネルが保持しているソケット数
3. /proc/net/route でルーティングテーブルを確認する
$ cat /proc/net/route Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0 00000000 0101A8C0 0003 0 0 100 00000000 0 0 0 eth0 0001A8C0 00000000 0001 0 0 100 00FFFFFF 0 0 0
ポート確認の詳細については「Linux ポート確認の全コマンド」も参照してください。
/proc/sys でカーネルパラメータを参照・変更する
1. /proc/sys の構造
/proc/sys 配下のファイルは読み取り専用ではなく、書き込むことでカーネルのランタイムパラメータを変更できます。sysctl コマンドはこの仕組みを利用しています。# IP フォワーディングの現在値を確認 $ cat /proc/sys/net/ipv4/ip_forward 0 # 一時的に有効化（再起動で元に戻る） $ echo 1 > /proc/sys/net/ipv4/ip_forward # sysctl コマンドで同等の操作 $ sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 0 $ sysctl -w net.ipv4.ip_forward=1 net.ipv4.ip_forward = 1
2. /proc/sys/kernel 配下の主要パラメータ
# 現在のホスト名（読み取り） $ cat /proc/sys/kernel/hostname server01.example.com # コアダンプファイルの命名パターン $ cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h # ランダムエントロピーの残量 $ cat /proc/sys/kernel/random/entropy_avail 3847
トラブルシュート｜/proc の値が想定と違う時の確認方法
/proc/meminfo の MemAvailable が少ないのにサービスは動いている場合
Cached（ページキャッシュ）が大量に確保されているケースが多い。Linux はメモリを積極的にキャッシュに使う設計で、これは正常動作です。# キャッシュの現在値を確認 $ grep -E "MemFree|Cached|MemAvailable" /proc/meminfo MemFree: 423104 kB Cached: 7418828 kB MemAvailable: 8921640 kB # MemAvailable = MemFree + SReclaimable + Cached（近似） # 本当に不足しているかはMemAvailableで判断する
プロセスの /proc/[PID] が消えてしまった場合
プロセスが終了すると /proc/[PID] ディレクトリは即座に消えます。ゾンビプロセス（State: Z）は /proc 上には残り続けますが、親プロセスが wait() しないと回収されません。# ゾンビプロセスの確認 $ grep -l "^State:.*Z" /proc/[0-9]*/status 2>/dev/null /proc/9876/status $ cat /proc/9876/status | grep -E "Name|State|PPid" Name: defunct State: Z (zombie) PPid: 1234
/proc/net/tcp の STATE が大量に TIME_WAIT になっている
短時間接続を大量に行うアプリケーション（HTTP短期接続、ロードバランサー等）でよく発生します。# TIME_WAIT 数を確認 $ grep -c " 06 " /proc/net/tcp # 06 = TIME_WAITを表す16進数 # sysctl で再利用を有効化（一時的） $ sysctl -w net.ipv4.tcp_tw_reuse=1
本記事のまとめ
| 確認したい情報 | /proc の参照先 | 対応コマンド |
|---|---|---|
| 物理メモリ・スワップ残量 | /proc/meminfo |
free -h |
| CPU数・モデル・周波数 | /proc/cpuinfo |
lscpu |
| ロードアベレージ | /proc/loadavg |
uptime |
| プロセスのメモリ使用量 | /proc/[PID]/status |
ps aux |
| ソケット統計・TIME_WAIT数 | /proc/net/sockstat |
ss -s |
| ルーティングテーブル | /proc/net/route |
ip route |
| カーネルパラメータの確認・変更 | /proc/sys/ |
sysctl -a |
ハードウェアをより詳しく確認したい場合は「dmidecode でハードウェア情報を取得」も参考にしてください。
/procを読める習慣は、障害の「原因を探す力」の出発点になります
サーバーが重い・メモリが足りない・プロセスが暴走している——そのとき「どこを見るか」がすぐ分かると、対応スピードは別次元になります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：kubectlコマンドの使い方｜ポッド・デプロイメント管理とLinuxサーバーでの実践例
- この記事の属するカテゴリ：Linuxtipsへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます