web-dev-qa-db-ja.com

Linuxはメモリ需要が増加したときに大きなディスクキャッシュを解放しない

2.6.31-302 x86-64カーネルでUbuntuを実行します。全体的な問題は、「キャッシュ」カテゴリのメモリが増え続け、アプリケーションで必要になった場合でも解放または使用されないことです。

これが私が 'free'コマンドから得たものです。これらのどれも、一見普通ではないように見えます。

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5750320    1608172          0       7848    1443820
-/+ buffers/cache:    4298652    3059840
Swap:            0          0          0

誰かが最初に言うことは、「心配しないで、Linuxはそのメモリを自動的に管理する」ということです。はい、メモリマネージャーがどのように機能するかを知っています。問題は、それが正しいことをしていないということです。ここで「キャッシュされた」1.4 GBは予約されており、使用できないようです。

Linuxに関する私の知識から、3 GBは「無料」であることがわかります。しかし、システムの動作はそうではありません。ピーク使用時に1.6 GBの実際の空きメモリが使い果たされると、より多くのメモリが要求されると（そして最初の列の「空き」が0に近づくと）、OOMキラーが呼び出され、プロセスが強制終了され、問題が発生し始めます。 ただし-/ +バッファ/キャッシュ行の「空き」には、約1.4 GBの「空き」がまだあります。

重要なプロセスのoom_adj値を調整して、システムが危険にさらされないようにしましたが、それでも重要なプロセスが強制終了され、そのポイントに到達したくありません。特に、理論的には、1.4GBがディスクキャッシュのみを排除する場合は、まだ「無料」です。

ここで何が起こっているのか誰かが誰か知っていますか？ Linuxの「free」コマンドと「空きメモリがないのはなぜ」という馬鹿げた質問がインターネットに殺到し、そのためこの問題について何も見つけることができません。

最初に思い浮かぶのは、スワップがオフになっていることです。私たちはそれについて断固としたシステム管理者を持っています。それらがバックアップされている場合、私は説明を受け入れます。これは問題を引き起こす可能性がありますか？

実行後は無料ですecho 3 > /proc/sys/vm/drop_caches：

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5731688    1626804          0        524    1406000
-/+ buffers/cache:    4325164    3033328
Swap:            0          0          0

ご覧のように、ごくわずかなキャッシュが実際に解放されますが、約1.4 GBが「スタック」しているようです。もう1つの問題は、この値が時間とともに上昇するように見えることです。別のサーバーで2.0 GBがスタックしています。

私は本当にこの記憶を元に戻したい...どんな助けでも最もありがたいです。

cat /proc/meminfo何か価値がある場合：

# cat /proc/meminfo 
MemTotal:        7358492 kB
MemFree:         1472180 kB
Buffers:            5328 kB
Cached:          1435456 kB
SwapCached:            0 kB
Active:          5524644 kB
Inactive:          41380 kB
Active(anon):    5492108 kB
Inactive(anon):        0 kB
Active(file):      32536 kB
Inactive(file):    41380 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               320 kB
Writeback:             0 kB
AnonPages:       4125252 kB
Mapped:            42536 kB
Slab:              29432 kB
SReclaimable:      13872 kB
SUnreclaim:        15560 kB
PageTables:            0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3679244 kB
Committed_AS:    7223012 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        7696 kB
VmallocChunk:   34359729675 kB
DirectMap4k:     7340032 kB
DirectMap2M:           0 kB
linuxmemorymemory-usagedisk-cache
24
trisweb

私は自分の質問に対する答えを見つけました-wombleの助けのおかげです（必要に応じて回答を送信してください）。

lsof -sは、使用中のファイルハンドルを示し、キャッシュを占有するmmapされたログファイルが数ギガバイトあることがわかります。

Logrotateを実装すると、問題が完全に解決され、より多くのメモリを活用できるようになります。

また、スワップを再度有効にして、今後OOMキラーに問題が発生しないようにします。ありがとう。

8
trisweb

どうやら、postgresのshared_buffersはcachedに表示されますが、実際には簡単に破棄することはできません...参照 利用可能なメモリ（キャッシュ）にかかわらずOOM

1
Nickolay