Linux tidak membebaskan cache disk besar ketika permintaan memori meningkat

24

Menjalankan Ubuntu pada kernel 2.6.31-302 x86-64. Masalah keseluruhan adalah bahwa saya memiliki memori dalam kategori 'cache' yang terus naik dan tidak akan dibebaskan atau digunakan bahkan ketika aplikasi kita membutuhkannya.

Jadi inilah yang saya dapatkan dari perintah 'gratis'. Sekilas tidak ada yang terlihat seperti biasa.

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

Hal pertama yang akan dikatakan seseorang adalah "Jangan khawatir, linux mengelola memori itu secara otomatis." Ya, saya tahu bagaimana seharusnya manajer memori bekerja; masalahnya adalah itu tidak melakukan hal yang benar. The "cache" 1,4 GB di sini tampaknya sudah dipesan dan tidak dapat digunakan.

Pengetahuan saya tentang Linux memberi tahu saya bahwa 3 GB "gratis"; tetapi perilaku sistem mengatakan sebaliknya. Ketika 1,6 GB memori bebas nyata digunakan selama penggunaan puncak, segera setelah lebih banyak memori yang diminta (dan 'bebas' di kolom pertama mendekati 0) pembunuh OOM dipanggil, proses dibunuh, dan masalah mulai muncul meskipun 'gratis' di baris - / + buffer / cache masih memiliki sekitar 1,4 GB 'gratis'.

Saya telah menyetel nilai oom_adj pada proses utama sehingga tidak membuat sistem bertekuk lutut, tetapi meskipun begitu proses penting akan terbunuh, dan kami tidak pernah ingin mencapai titik itu. Terutama ketika, secara teoritis, 1.4GB masih "gratis" jika hanya akan mengusir cache disk.

Adakah yang tahu apa yang terjadi di sini? Internet dibanjiri dengan pertanyaan bodoh tentang perintah 'bebas' Linux dan "mengapa saya tidak memiliki memori bebas" dan saya tidak dapat menemukan apa-apa tentang masalah ini karena itu.

Hal pertama yang muncul di kepala saya adalah bahwa swap tidak aktif. Kami memiliki sysadmin yang bersikeras tentang hal itu; Saya terbuka untuk penjelasan jika didukung. Mungkinkah ini menyebabkan masalah?

Ini gratis setelah berjalan 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

Seperti yang Anda lihat, beberapa jumlah cache yang sangat kecil sebenarnya dibebaskan, tetapi sekitar 1,4 GB tampaknya "macet." Masalah lainnya adalah bahwa nilai ini tampaknya meningkat seiring waktu. Di server lain 2,0 GB macet.

Saya benar-benar ingin memori ini kembali ... bantuan apa pun akan sangat dihargai.

Inilah cat /proc/meminfojika itu layak apa pun:

# 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
linux  memory  memory-usage  disk-cache 
— trisweb
sumber
3
Saya tidak memiliki penjelasan apa pun untuk cache Anda (walaupun saya menduga bahwa file mmap'd mungkin masuk ke dalamnya), tetapi untuk kebaikan umat manusia, ambil sekop dan kapur api dan singkirkan "Anda tidak perlu bertukar jika Anda punya banyak RAM! " pendorong. Mereka kebal terhadap diskusi rasional, dan mereka salah besar. Fakta bahwa pembunuh OOM menguntit Anda hanyalah salah satu gejala dari ini.
— womble
Pikiranku persis. Terima kasih atas sarannya. Apakah Anda tahu artikel atau argumen bagus lainnya tentang mengapa swap diperlukan?
— trisweb
6
Karena jika Anda tidak memiliki swap, hal-hal seperti ini terjadi. Tapi jangan repot-repot mencoba berdebat dengan denier swap Anda; baik mengeluarkan quicklime atau mengatakan "jika Anda tidak ingin bertukar di sini, Anda memperbaiki kekacauan ini yang Anda bersikeras untuk membuat". Mereka akhirnya akan berubah pikiran sendiri atau mereka akan mati berusaha. Masalah diselesaikan dengan cara apa pun.
— womble
Luar biasa, terima kasih atas tipsnya. Anda benar tentang file mmap'd by the way - sebuah lsof cepat menunjukkan pertunjukan file log mengambil memori. Membersihkan mereka memecahkan masalah.
— trisweb
Masalahnya adalah bahwa tanpa swap, hasil overcommitting dalam menjalankan pembunuh OOM dan tidak overcommitting hasil dalam sistem yang tidak dapat memulai proses. Anda perlu swap untuk menggunakan RAM secara efektif.
— David Schwartz

Jawaban:

8

Saya telah menemukan jawaban untuk pertanyaan saya sendiri - terima kasih atas bantuan womble (kirimkan jawaban jika Anda mau).

lsof -s menunjukkan pegangan file yang digunakan, dan ternyata ada beberapa gigabyte file log mmap'd mengambil cache.

Menerapkan logrotate harus menyelesaikan masalah sepenuhnya dan memungkinkan saya untuk memanfaatkan lebih banyak memori.

Saya juga akan mengaktifkan kembali swap sehingga kami tidak memiliki masalah dengan pembunuh OOM di masa depan. Terima kasih.

— trisweb
sumber
2
Halaman mmap akan dibuang sehingga tidak boleh menyebabkan cache disematkan. Apakah Anda menggunakan ramf?
— psusi
Hai, maaf karena menggali utas lama, tapi saya menghadapi masalah yang sama saat ini dan lsof -stidak menunjukkan penggunaan yang tidak biasa. Namun, saya menggunakan ramf seperti yang Anda katakan [dan kernel 2.6.10, yang tidak memiliki fitur drop_caches]. Menurut Anda apa yang diduga sebagai tersangka?
— Ram
1
Terima kasih atas tipnya! Saya menambahkan lsof -s | sort -rnk 7 | lesske kotak alat saya sekarang. Catatan untuk pembaca lain: ini mungkin suka entri besar /proc/net/rpc/nfs4.nametoid/channel, tetapi ternyata bukan pelakunya dalam kasus saya.
— Nickolay
pastikan file atau program besar Anda tidak menggunakan mlock. di /proc/meminfolihat halaman "Tidak bisa diganggu gugat".
— Michael Martinez
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.