Linux OSリソースのパフォーマンス分析(2) ～ CPUとメモリの使用状況を分析してみよう

性能改善ノウハウを現場から直送！ NTTデータのよりぬき『週刊まかせいのう』　第6回

詳細なメモリ使用状況の分析

/proc/meminfoからは、より詳細なメモリ情報を確認することができます^[7]。

実行コマンド

while [ 1 ]
  do
    cat /proc/meminfo | awk '{print(strftime("%Y/%m/%d %H:%M:%S"),$0);fflush();}'
    sleep 10
  done

出力結果のサンプル

2015/10/26 15:08:59 MemTotal:        1011932 kB
2015/10/26 15:08:59 MemFree:          108196 kB
2015/10/26 15:08:59 Buffers:          177340 kB
2015/10/26 15:08:59 Cached:           516408 kB
2015/10/26 15:08:59 SwapCached:          332 kB
2015/10/26 15:08:59 Active:           629792 kB
2015/10/26 15:08:59 Inactive:         124720 kB
2015/10/26 15:08:59 Active(anon):      47732 kB
2015/10/26 15:08:59 Inactive(anon):    57004 kB
2015/10/26 15:08:59 Active(file):     582060 kB
2015/10/26 15:08:59 Inactive(file):    67716 kB
2015/10/26 15:08:59 Unevictable:           0 kB
2015/10/26 15:08:59 Mlocked:               0 kB
2015/10/26 15:08:59 SwapTotal:       2031608 kB
2015/10/26 15:08:59 SwapFree:        2028524 kB
2015/10/26 15:08:59 Dirty:                52 kB
2015/10/26 15:08:59 Writeback:             0 kB
2015/10/26 15:08:59 AnonPages:         60552 kB
2015/10/26 15:08:59 Mapped:            50252 kB
2015/10/26 15:08:59 Shmem:             43972 kB
2015/10/26 15:08:59 Slab:             118652 kB
2015/10/26 15:08:59 SReclaimable:      90064 kB
2015/10/26 15:08:59 SUnreclaim:        28588 kB
2015/10/26 15:08:59 KernelStack:        2440 kB
2015/10/26 15:08:59 PageTables:         6860 kB
2015/10/26 15:08:59 NFS_Unstable:          0 kB
2015/10/26 15:08:59 Bounce:                0 kB
2015/10/26 15:08:59 WritebackTmp:          0 kB
2015/10/26 15:08:59 CommitLimit:     2537572 kB
2015/10/26 15:08:59 Committed_AS:    1084120 kB
2015/10/26 15:08:59 VmallocTotal:   34359738367 kB
2015/10/26 15:08:59 VmallocUsed:      342908 kB
2015/10/26 15:08:59 VmallocChunk:   34359380056 kB
2015/10/26 15:08:59 HardwareCorrupted:     0 kB
2015/10/26 15:08:59 AnonHugePages:     30720 kB
2015/10/26 15:08:59 HugePages_Total:       0
2015/10/26 15:08:59 HugePages_Free:        0
2015/10/26 15:08:59 HugePages_Rsvd:        0
2015/10/26 15:08:59 HugePages_Surp:        0
2015/10/26 15:08:59 Hugepagesize:       2048 kB
2015/10/26 15:08:59 DirectMap4k:        9920 kB
2015/10/26 15:08:59 DirectMap2M:     1030144 kB

主な出力項目の説明

項目	意味
MemTotal	物理メモリの総量
MemFree	空きメモリ
Buffers	メタデータ用キャッシュの使用量
Cached	ディスクキャッシュの使用量。Shmemを含むことに注意
Active(anon)	最近利用されたメモリ（スワップアウト対象）
Inactive(anon)	最近利用されていないメモリ（スワップアウト対象）
Active(file)	最近利用されたメモリ（キャッシュ解放対象）
Inactive(file)	最近利用されていないメモリ（キャッシュ解放対象）
SwapTotal	スワップ領域の総量
SwapFree	スワップ領域の未使用量
Dirty	ディスク書き込みが完了していないメモリ
Shmem	プロセス間共有メモリの使用量（tmpfsが使用するメモリ）
Slab	スラブキャッシュの使用量
SReclaimable	解放可能なスラブキャッシュ
SUnreclaim	使用中の（解放できない）スラブキャッシュ

注

[7]: カーネルのバージョンによって取得できる情報が異なるので注意してください。

利用可能メモリの算出

実は、最近のバージョンのカーネルまで、利用可能メモリを一目で確認できる項目は存在しませんでした。このため、実態に近い利用可能メモリは、以下の式で算出したサイズの8割程度を安全率と見ておくとよいでしょう^[8]。

「MemFree＋Active(file)＋Inactive(file)＋SReclaimable」

または、

「MemFree＋Buffers＋Cached－Shmem＋SReclaimable」

RHEL7以降では、利用可能メモリを一目で確認できるMemAvailableが追加されていますので、この項目を利用しましょう。またRHEL6.6以降でも、カーネルパラメータvm.meminfo_legacy_layout=0を設定するとMemAvailableを取得可能になります^[9]。

注

[8]: RHEL5までは、Shmem（プロセス間共有メモリ）とSReclaimable（解放可能なスラブキャッシュ）を/proc/meminfoから取得できません。プロセス間共有メモリおよびスラブキャッシュの使用量を確認するには、後述する解説を参考にしてください。

[9]: 参考資料：米Red Hat「Backport “MemAvailable” field to /proc/meminfo in Red Hat Enterprise Linux 6.」

分析のポイント

vmstatコマンドの解説と一部重複する部分もありますが、meminfoで性能に関わる主要な項目をチェックします。

利用可能メモリに十分な余裕があるか

余裕の判断基準はシステム特性によりますが、基本的には物理メモリ総量の2割を下回っていなく、かつ今後アプリケーションが使用する可能性のあるメモリを確保可能かどうかで判断するとよいでしょう。メモリ使用量の多いプロセスを確認するには、先に紹介したps -eF --sort=rssコマンドが便利です。

利用可能メモリが時系列経過とともに減少しているか

利用可能メモリの減少傾向が見られる場合、メモリリークが発生している可能性があります。メモリ使用量が増加し続けているプロセスが存在するか確認しましょう。

スワップ領域の未使用量（SwapFree）が不足しているか

スワップ領域の大半が使用されている状況は、メモリ不足と考えられます。このような状態になると、ディスクキャッシュが縮小されたり、カーネルの判断でプロセスが強制終了されたりする危険性があります。明らかにスワップ領域の総量が小さい場合は別ですが、基本的にはメモリ増設を検討しましょう。

スラブキャッシュ（Slab、SReclaimable）が肥大化しているか

特定のカーネル資源が大量に格納されると、その資源の排他制御に起因してCPU(%sys)が高負荷を示すことがあります。このような事象は、利用可能メモリだけに着目していてもなかなか気付くことができません。例えば、膨大な数のファイル（PATH）にアクセスするアプリケーションでは、ディレクトリエントリやiノードキャッシュが肥大化しやすい傾向があります。どのようなカーネル資源がスラブキャッシュに格納されているかを確認するにはslabtopコマンドが便利です。

プロセス間共有メモリ（Shmem）が肥大化しているか

プロセス間共有メモリの使用量が過剰な場合、利用可能メモリが圧迫されることでスワップ頻発を招きやすくなります。特にデータベースなどのアプリケーションではプロセス間共有メモリを多用する傾向があるため、使用量に注意しましょう。

プロセス間共有メモリの分類として、POSIX共有メモリとSystemV共有メモリがあります。POSIX共有メモリの使用量はdf -kコマンド結果のtmpfsの使用量で確認できます。SystemV共有メモリの使用量はipcs -umコマンド結果のpages resident（固定されたページ）×ページサイズ（標準は4kB）で確認できます。

Dirtyが肥大化しているか

Dirtyのサイズが所定の閾値を超えるとディスク書き出しが行われますが、Dirty量が多ければ書き出し待ちが長時間化しやすく、突発的なI/O待ちに伴う処理遅延が発生する可能性があります。大量メモリを搭載するサーバでは、ディスクキャッシュを多く確保されやすいため、Dirtyのもととなる大量WriteI/Oに注意すべきです。処理遅延に対してシビアなシステムでは、フラッシュアレイやSSDなどI/O応答が高速なストレージを採用したり、WriteI/O周りのチューニングが必要になるでしょう。

＊　　　　＊　　　　＊

いかがでしたでしょうか。次回は、ストレージとネットワークの使用状況について、どのような観点から分析を行っていくかを解説したいと思います。