Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。分析のポイントメモリ使用状況の分析メモリは、ユーザアプリケーションやカーネルを実行するために必要なリソースです。Linuxにおけるメモリ管理の仕組みは複雑で、その仕組みはカーネルのバージョンアップとともに改良されています。ここではメモリ使用状況を分析するにあたって、ポイントとなるいくつかの考え方を紹介します。メモリ使用状況について誤解されやすい点について触れておきます。Linuxは、メモリに空きがあれば可能な限りディスクキャッシュとして確保することで、次回以降の読み込みを高速化しています。このキャッシュ確保によって空きメモリ(MemFree)が少なく見えますが、空きメモリ不足時にはカーネルの判断でキャッシュが解放され、空きメモリとして再利用できます。Javaアプリケーションなどでは、アプリケーションが使用するメモリの最小/最大サイズを指定できますが、実際に使用されるメモリは、アプリケーションが割り当てたメモリにデータを書き込んだ分となります。このような特性から、メモリはCPUとは異なり、必ずしもスループットに比例してメモリ使用量が増加するわけではありません。メモリ使用状況を分析する際には、システム負荷の平常時とピーク時で比較することが望ましいです。利用可能メモリについてメモリ使用状況について、性能観点で特に意識しておきたいのは利用可能なメモリです[5]。空き(未使用な)メモリが不足すると、必要なメモリを確保するため、カーネルの判断で次のような動作が行われます。「空きメモリ+解放可能なキャッシュ」ということになります。全てのキャッシュを解放可能と見なすことは、性能観点からは望ましくないと考えられます。この理由は2つあります。1つは、キャッシュサイズが小さくなると、キャッシュを利用する処理で遅延するおそれがあるためです。このような状況下ではカーネルの判断によって、キャッシュを解放せずにスワップアウトが選択されることがあります。1つは、キャッシュの解放待ちに伴う処理遅延です。WriteI/Oによって更新されたキャッシュはDirtyと呼ばれ、まだディスクに書き込みが完了していない状態です。このDirtyなキャッシュを解放する際には、ディスク書き込みが完了するまで待ちが発生します。それでは、このような仕組みを念頭において、メモリ使用状況を確認していきましょう。ここでいう利用可能メモリとは、すでに使用中のメモリは含めません。大まかなメモリ使用状況の分析vmstatは、CPU、メモリ、ストレージに関する情報を出力するコマンドです。取得粒度が粗いため詳細な分析には不向きですが、大まかなメモリ使用状況をリアルタイムに確認する用途に向いています。スワップアウト※された量(kB/秒)※スワップインは、スワップ領域(ディスク)からメモリへ書き出す処理。スワップアウトは逆に、メモリからスワップ領域(ディスク)へ書き出す処理。vmstatコマンドが初回に出力するデータは、サーバ起動時からの平均値です。大まかな利用可能メモリの算出まずは、大まかな利用可能メモリとして「free+cache」で算出し、安全率として8割程度で見ておくとよいでしょう[6]。この式は多少誤差を含むものの、利用可能メモリ不足をなるべく簡易にチェックすることを意図しています。厳密に見るとbuffも加算対象といえますが、cacheと比べるとbuffは相対的にサイズが小さいため、安全側に倒す意味でも加算は行わずに評価してよいでしょう。実態に近い利用可能メモリは、後述する/proc/meminfoから確認します。RHEL7以降では「free+cache」ではなく、/proc/meminfoのMemAvailableで利用可能メモリを確認してください。分析のポイント利用可能メモリに十分な余裕があるか余裕の判断基準はシステム特性によりますが、基本的には物理メモリ総量の2割を下回っておらず、かつ今後アプリケーションが使用する可能性のあるメモリを確保可能かどうかで判断するとよいでしょう。Javaアプリケーションで使用する最大メモリサイズを6GBで設定しているけれども、まだ2GBしか使われていなければ、今後さらに4GB使用される可能性があります。--sort=rssコマンドが便利です。Size)は、スワップされていない物理メモリ使用量(kB)を意味します。--sort=rssコマンドは、RSSの昇順でプロセスの一覧を表示します。RSSの値は共有メモリを含んでおり、その分はプロセス間で重複カウントされます(単純にRSSを合算してもOS全体のメモリ使用量とは一致しません)。プロセス間共有メモリの使用量を確認するには、後述する/proc/meminfoの解説を参考にしてください。利用可能メモリが時系列経過とともに減少しているか利用可能メモリの減少傾向が見られる場合、メモリリークが発生している可能性があります。メモリ使用量が増加し続けているプロセスが存在するか確認しましょう。スラブキャッシュが肥大化している可能性もあるため、後述する/proc/meminfoで詳細を確認します。siおよびsoが頻発しているかsiおよびsoが頻発している場合(すなわち0でない値が定常的に計上されている場合)、メモリ不足が発生している可能性が高いです。スワップアウトは利用頻度の低いメモリをディスクに書き込むため、I/O待ちに伴う処理遅延を招くおそれがあります。利用可能メモリに余裕があるように見える状況でも、スワップアウトがたまに発生するケースがあります。これはカーネルの判断で、空きメモリやキャッシュをなるべく確保するため、利用頻度の低いメモリをスワップアウトしてるからです。この場合は、iostatコマンドの結果などでI/O待ちがとくに発生していなければ問題ありません。したがって、あくまで「siとsoの両方が」「定常的に」発生しているかどうかという観点で確認します。ショウゴ)NTTデータの性能プロフェッショナルチーム「まかせいのう」の古参メンバ。12年前、大規模プロジェクトの性能課題に直面し、満身創痍になる日々を経験する。からくも性能改善できたときの喜びをきっかけに、現場の教訓とともに性能の道を歩むことを決意する。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。プラットフォームチームの意義と実践のポイント1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。