システムの安定したパフォーマンス発揮を維持するためには、システムを構成する各機器において適切なメモリ量が常に利用可能な状態である必要があります。
一般的に、メモリ量が十分かどうかをチェックする方法としては、物理メモリ(主記憶)の空きメモリ量のチェックが行われています。
しかし、最近のOSにおいては、システムが性能向上のためにキャッシュやバッファリングを行っているため、物理メモリの空き容量のみに着目していると性能的な影響度がはっきり見えてこないことがあります。
今回は、性能管理においてどのようにメモリを管理すれば良いのかを示します。
物理メモリの空き容量の確認方法
物理メモリの空き容量とは、マシンに装着されている主記憶用の物理的なメモリ中でプログラムやデータ等が何も割り当てられていない部分の容量を指します。何も割り当てられていなければ、即座に新しいプログラムやデータが使用することが出来るため、“基本的には”この物理メモリに余裕がある限りは、メモリの不足の問題は無いと考えてよいでしょう。以下、OS毎に取得方法を示します:
o Windows(NT系)OSの場合には、タスクマネージャのパフォーマンスから現在の物理メモリの空き容量が容易に確認できます。
o UNIX系のOSの場合には、vmstat、top、sar、free等のコマンドによって物理メモリの空き容量が確認出来ます。
物理メモリ計測に依存する問題点
しかし、今日のOSでは、単純に物理メモリの空き容量だけに着目していては、メモリ不足の状態を適切に把握することは出来ません。
一般的に、各OSでは、応答速度を高速化するために、メモリと比べてスループットの低いディスク機器に対するアクセスを出来るだけ減らすべく、バッファ・キャッシュ機能を頻繁に利用しています。ディスク上の各種データの実態をメモリ上にコピーして配置し、そのコピーされたデータをあたかもディスク上のデータのようにアプリケーションに見せかけて利用させることで、高速の読み出しと書き込みを実現している訳です。
ところが、このバッファやキャッシュは現在使用していないメモリ領域を恒常的に確保するために、実際のメモリ空き容量が見えにくくなります。特に Linux等では、一度走査したディスクブロックイメージを、可能な限りバッファ領域にコピーしてしまうため、一定時間以上運用を行うと、残り空き物理メモリが数MB程度になっていることがあります。ただ、これらで確保されているメモリ領域は必ずしも不可欠な情報では無く、あくまでシステム高速化の為のバッファやキャッシュですので、アプリケーションが新たにメモリを必要とする際には、バッファやキャッシュを取り崩して必要量を獲得することが出来るため、例えば物理メモリ量が残り少ない状態であってもメモリ不足であるとは限りません。
このようにシステムの実態と物理メモリの占有の状態が異なっている場合には、物理メモリの計測だけでは、メモリの適切な過不足を把握しきれません。今日の OSでは、バッファやキャッシュ機能は多用されているため、当然物理メモリ以外にも着目したメモリの性能管理が必要となります。
簡単な切り口 ~バッファやキャッシュサイズを計測する~
この問題に対する最も簡単な対処方法は、残りメモリ量を計測する際に、物理メモリの空き容量だけではなく、それにバッファやキャッシュの量を加算した値を空きメモリ量として理解することです。
例えばWindowsサーバーの場合、タスクマネージャーのパフォーマンスにおいて、物理メモリの欄に利用可能(物理メモリの空き容量)とシステムキャッシュが表示されており、その合計が現在利用可能なメモリ量と考えることが出来ます。
Linuxの場合にはfreeコマンドを使用すれば、物理メモリの空き容量に、バッファとキャッシュを加算した値をそのまま得ることが出来ます。
(例) $ free
total | used | free | shared | buffers | cached | |
Mem: | 253504 | 248632 | 4872 | 0 | 61508 | 57436 |
-/+ buffers/cache: | 129688 | 123816 | ||||
Swap: | 522072 | 0 | 522072 |
ただ、メモリによるシステムの性能劣化の兆候や要因を把握するためには、単純にバッファやキャッシュサイズを物理メモリ量の空き容量に足したサイズのチェックだけでは不十分です。何故ならば、キャッシュやバッファの量が低下するとシステムのキャッシュ効率が悪化して、ディスクアクセスが多発することにつながるため、システムの処理性能への影響が否めないからです。また、通常のシステムでは、ある程度のバッファやキャッシュを残していても、割り当てメモリのうちのいくつかを物理メモリでは無く、ディスク上の記憶領域であるスワップ領域に配置し、物理メモリの空き容量に余裕をもたせようとすることがあります。このようにしてスワップ領域にコピーが行われると、ディスクアクセスの遅さや、再配置の処理負荷等で処理性能に影響します。
このように物理メモリの残量にキャッシュやバッファの量を足したメモリ残量だけでは、性能問題を測りきれないケースが存在するので注意が必要です。一般的に、物理メモリやバッファやキャッシュが多く残っている場合にはあまり気にする必要は無いのですが、残量が少なくなってくると、キャッシュ効率やスワップ量への注意の必要性が高くなります。それぞれ残量がどのくらいで影響が出てくるかについては、OSの仕様、メモリサイズ、バッファやキャッシュのシステム設定等に依存するだけではなく、アプリケーションの振る舞いや運用状況によっても異なってくるため、一概には言えないという難しい性質があります。
このようなメモリの限界状態の把握方法について、以下に解決法を示します。
キャッシュ効率の確認
システムにおいてバッファやキャッシュが有効に働いている場合には、アプリケーションからの要求によるファイルアクセス数に対して、実態のディスク上のファイルデータへのアクセスは低くなりますが、その程度をキャッシュ効率とみなす事が出来ます。以下の方法で把握出来ます。
* Windowsサーバーの場合
パフォーマンスカウンタの Cache: Copy Read Hits % (読み込みキャッシュ効率)が、システムによりますが、80%以上の高い数値を示していればキャッシュ効率が高く、またキャッシュメモリ不足ではなく、性能問題にも影響を与えていないと考えて良いでしょう。また、見方としては他にも、Memory: Cache Faults/secと、Cache: Copy Reads/secを比較して、率だけでなく頻度にも着目する方法もあります。
* Solarisの場合のsarコマンドを使用した取得例
以下のコマンドを実行します。
$ sar -b 1
14:13:49 bread/s lread/s %rcache bwrit/s lwrit/s %wcache pread/s pwrit/s
14:13:50 0 0 100 0 0 100 0 0
上記の%rcacheが読み込みキャッシュヒット率、%wcacheが書き込みキャッシュヒット率です。平均的に数字が高いほどキャッシュ効率が高く、キャッシュメモリ不足ではなく、性能問題にも影響を与えていないと考えて良いでしょう。また、この比率は、lreads、lwritというバッファヒット回数とbread、 bwritというディスク読み込み回数の件数から算出しており、これらを参照することで頻度についても把握することが出来ます。
これらキャッシュヒット率は、一概に80%以上であったらOKとみなすより、システムの安定運営の元で一定期間サンプリングしておき、それらの平均値と比べて著しく低い値を示した場合には特に注意するというような、運用監視型のアプローチをとるべきでしょう。通常より明らかにキャッシュヒット率が落ち込んでいる場合には、かなりの確度でシステムに性能的な劣化現象が生じているものと考えて良いでしょう。
スワップ頻発状況の計測
システムにおいて、スワッピング/ページングが頻繁に発生している場合には、主記憶よりもスループットの低いディスクアクセスが頻発し、また、カーネルが複雑な仮想記憶管理を行うことの負荷により、システムの処理性能が低下します。その為、スワップ発生やその頻度には特に注意をし、以下の方法で監視するようにします。
1. 仮想記憶サイズやスワップサイズの全体量
Windowsでは、タスクマネージャのパフォーマンス等から把握できるコミットチャージの合計値が、物理メモリの合計を上回っていないかどうかまず確認します。この値が上回っている場合には、システムが使用しているメモリの総量が物理メモリサイズを超えることを示し、その過剰分は確実にディスク上に配置されることになります。またその際には、ある程度のメモリ読み書きを必要とする処理が行われた場合には、その都度スワップ処理が発生することになります。
UNIX系システムの場合:
基本的にはvmstatが主流ですが、OS毎に若干異なりますので以下に示します。
・Linux: vmstat, free
・FreeBSD: vmstat, swapinfo
・Solaris: swap -s, vmstat(空きswapサイズ)
・HP-UX: swapinfo
・AIX: swapon -s
OSによってメモリに余裕がある場合には、スワップサイズが0のものと、最初からある程度確保されているものがあります。
2. 仮想記憶サイズやスワップサイズの増減に注目 スワップやページが頻繁に変動する場合には、パフォーマンスに影響を及ぼします。
UNIX系であれば、vmstatのsi(Swap In)、so(Swap Out)や、上記のスワップサイズが変動していないかを観測していれば、スワッピングが起きているかどうか把握出来ます。ただ、大きいサイズの変動があっても発生頻度が少ない場合よりも、サイズは小さくとも小刻みに大量の件数が発生し続けている方が、他の処理の妨げになり応答性能に影響します。そのため、 sarやその他のコマンドにより、秒間あたりの発生頻度等にも注意する必要があります。 Windows系では、Memory: Page/secに注目することで、ページングの発生頻度を把握することが出来ます。
3. ディスクのビジー率による性能劣化にも注意
上記 2. のスワップやページングの発生頻度が秒間あたり平均で約4件以上発生している場合には、システムの応答性能は劣化の傾向になる可能性が高い訳ですが、ディスクのビジー度が高い場合には、更に読み込み待ち/書き込み待ちが発生して応答速度が遅くなります。これらの大幅な遅延減少を把握するためには、ディスクデバイスのビジー率や、処理待ち発生をチェックすることになります。
Windowsの場合:
Physical Disk: % Disk Time(ディスクビジー率)30以上の場合には注意
Physical Disk: Avg. Disk Queue Length(処理待ち行列)2以上の場合には注意
UNIXの場合:
iostat -x で、%util, %w, %r 等を把握(ディスクビジー率)
iostat -x で、avgqu-sz, wait 等を把握(処理待ち行列)
まとめ:システム性能管理のためのメモリ把握方法
以下にシステムのパフォーマンス維持のためのメモリチェックの順序をまとめます。
1. 十分な物理メモリ残量があるか確認する。
バッファやキャッシュの加算値でも考える。
2. バッファやキャッシュの増減を確認する。
3. スワップサイズや発生の増減を確認する。
4. ディスクデバイスの使用頻度を確認する。