システム管理
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

有効なメモリ量

うえたけ
時折のアドバイザー

有効なメモリ量

ご存知の方いましたら教えて下さい。

アプリケーションにとって有効な実メモリ量(SWAPを発生させず使用できるメモリ量)は下記で算出できると考えています。

・topのREAL_TOTAL+FREE

しかし、上記式の結果が搭載メモリ量に対して、とても小さいです(例えば8GB搭載に対して、5GBくらいになるサーバがあります)。

この有効メモリ量を増やす設定はあるのでしょうか?

当初試算より早くSWAPが発生して困っています(8GBフルに近く使えるのかと思っていたのですが、アプリのメモリ使用量が6GBぐらいに関わらずSWAPを起こしていたところから辿り着きました)

よろしくお願いします。
5 件の返信
hazelwood
信頼あるコントリビューター

有効なメモリ量

対策案としては、バッファキャッシュのサイズを制限してみてはどうでしょうか?(カーネルパラメータdbc_max_pct)

なお、アプリケーションで利用できるメモリ量については、crashconf(1M)のUNUSED+USERPGがより正確だと思います。
うえたけ
時折のアドバイザー

有効なメモリ量

ご返信ありがとうございます。

ただ、バッファキャッシュをチェックしてみたところ、それ以外の原因もある気がしています。まだ改善点や気づかれた点ありましたらアイディア頂けますでしょうか?

参考までに下記のような状態でした。

�搭載、�dmesgのavail、�top、dbc_max_pct=10

� �*0.9 � �*0.9 �

--- ------ --- ------ ---

8.0 7.1 7.2 6.4 5.5

�、�のどちらでdbc_max_pcを考慮すべきか分からなかったので両方で計算してみましたが、どちらにせよ有効なメモリ量がまだ少なすぎると思っています。さらにメモリを搭載したマシンでみると差が顕著に見えます(割合は同じですが)。

ちなみにcrashconfの使用方法はまだ不明なのでtopとつきあわせています。
oops
貴重なコントリビューター

有効なメモリ量

Glance があれば分かりやすいんですが…。

物理メモリの総量は以下のようになります。

System(カーネル使用) + BufferCache + User(ユーザプロセス使用) + Free

すべてがユーザで使用できる訳ではありません。

hazelwood さんが言われている crashconf を使うと、glance がなくてもその辺の内訳がよくわかります。

# crashconf -v

CLASS PAGES INCLUDED IN DUMP DESCRIPTION

-------- ---------- ---------------- -------------------------------------

UNUSED 159499 no, by default unused pages

USERPG 131364 no, by default user process pages

BCACHE 52410 no, by default buffer cache pages

KCODE 2572 no, by default kernel code pages

USTACK 1487 yes, by default user process stacks

FSDATA 18 yes, by default file system metadata

KDDATA 151449 yes, by default kernel dynamic data

KSDATA 25485 yes, by default kernel static data

Total pages on system: 524284

Total pages included in dump: 178439

DEVICE OFFSET(kB) SIZE (kB) LOGICAL VOL. NAME

------------ ---------- ---------- ------------ -------------------------

31:0x016000 310112 1048576 64:0x000002 /dev/vg00/lvol2

----------

1048576

Description があるから分かりやすいと思います。

単位はページですので、4 をかけると kb になります。

ユーザが使えない部分としては、カーネルのテキスト、データ、スタック部分である、

KCODE、KDATA、KSTACK

それからファイルシステムのメタ(管理)データ部分

FSDATA

それから Buffer Cache

BCACHE

ユーザプログラムで使っている部分は

USERPG と USTACK

になります。

物理メモリ搭載量が大きいシステムでは、カーネルが使用するメモリもやはり大きくなってきます。

この辺りはカーネルパラメータのチューニングにもよりますが。
ez2000i
時折のビジター

有効なメモリ量

私もcrashconfの値がより正確だと思います。

メモリはユーザが全て使える訳では無く、OS=カーネルも乗っかります。

私の方のシステムでは10GBのメモリがありますが、

crachconf -v の結果は以下の通りです。

crashconfのmanページと合わせて確認して下さい。

--------------------

UNUSED 1654933

USERPG 509477

BCACHE 130760

KCODE 1977

USTACK 4736

FSDATA 312

KDDATA 171564

KSDATA 147681

--------------------

Total pages on system: 2621440

上記はページ(4KB)単位なので、

Total=(2621440*4)=10485760/1024=10240MB=10GB

となります。

メモリにはユーザプログラム以外に、

バッファキャッシュ(上記BCACHE+FSDATA)やカーネル(上記KCODE+KSDATA+KDDATA)が格納されます。

ちなみにこちらのバッファ設定では512MBを設定して

いますので、BCACHEとFSDATAを合わせた値は512MBです。

尚、メモリ上のカーネルサイズはカーネルパラメータの設定値や接続されている周辺機器の数等により異なります。

よって、同じメモリ量のシステムでも、システム設定内容の違いがあれば、使用可能なメモリ量は異なります。
うえたけ
時折のアドバイザー

有効なメモリ量

みなさま、有用な情報をありがとうございます。

crashconfでチェックしたところ、下記のようになりました(manを読むと、何やら怖そうだったので躊躇していました)。

CLASS PAGES MB

UNUSED 383622 1498.5

USERPG 1054374 4118.6

BCACHE 209219 817.3

FSDATA 496 1.9

USTACK 17197 67.2

KCODE 2520 9.8

KDDATA 327582 1279.6

KSDATA 102142 399.0

TOTAL 8192.0

ユーザ 5617.2

カーネル 1688.5

ユーザ 68.6

カーネル 20.6

カーネルのメモリ使用量が多いと感じました。他HPサーバでもこれぐらいの割合で占めていました(こんなにカーネル使用があるとは想定していませんでした)。

この割合を下げることは可能なのでしょうか?それともしょうがないことなのでしょうか?みなさんのサーバ情報を拝見しても高いので、下げることは不可なのか、と気を落としてかけているのですが。

また、バッファキャッシュについては搭載メモリの過多に関わらず一律にdbc_max_pctを10に設定していたのは、メモリが多いサーバには無駄かな、と思いました。少しチューニング幅が出てきたと考えています。ありがとうございます。