Mengapa menjatuhkan cache di Linux?


84

Di server kami, kami memiliki kebiasaan menjatuhkan cache di tengah malam.

sync; echo 3 > /proc/sys/vm/drop_caches

Ketika saya menjalankan kode itu sepertinya membebaskan banyak RAM, tetapi apakah saya benar-benar perlu melakukannya. Bukankah RAM gratis terbuang sia-sia?


62
Temukan orang yang memasukkan ini dan tanyakan kepadanya mengapa dia melakukannya. Seperti yang Anda tebak dengan benar, tidak ada alasan yang jelas untuk itu.
Michael Hampton

10
Melakukan debug kernel. Itu saja. Ini sebenarnya tidak membebaskan RAM apa pun; itu menjatuhkan cache, seperti namanya, dan dengan demikian mengurangi kinerja.
Michael Hampton

28
@ivcode Kemudian Anda harus mencari dan memperbaiki masalah dengan server itu daripada mencoba menghindari kondisi yang menyebabkannya. Jika mobil saya macet setiap kali saya belok ke kanan, menghindari belokan kanan yang tajam adalah perbaikan yang buruk.
David Schwartz

7
Terkait thedailywtf.com/Articles/Modern-Memory-Management.aspx Sangat beralasan itu adalah ide yang buruk.
Drunix

7
Terkait, dan deskripsi yang berguna dari "masalah": linuxatemyram.com
Bill Weiss

Jawaban:


86

Anda 100% benar. Ini bukan praktik yang baik untuk membebaskan RAM. Ini mungkin merupakan contoh administrasi sistem kultus kargo.


9
+1 untuk menyebutkan Administrasi Sistem Kargo Kargo. Setiap sysadmin yang tidak tahu istilah itu dan apa artinya harus dipecat.
Tonny

8
@ Tony: Kami akan dibiarkan tanpa departemen sysadmin kemudian :(
PlasmaHH

2
Seperti kebanyakan manusia, saya suka pernyataan singkat kurang ajar dengan banyak persetujuan, tetapi kutipan atau alasan akan menghasilkan +1 superego saya.
Aaron Hall

2
Jelaskan administrasi kultus kargo, serta yang di atas, jika Anda tidak keberatan. Mungkin dalam edit lanjutan? Saya masih menahan +1 saya ...: P
Aaron Hall

2
"Mungkin saja meskipun aplikasi Anda mungkin tidak menggunakan RAM ini tetapi Linux melakukan cache secara agresif ke dalam memorinya dan meskipun aplikasi tersebut membutuhkan memori, ia tidak akan membebaskan sebagian dari cache ini tetapi lebih baik mulai bertukar." Tidak terlalu spesifik. Dalam praktiknya, manajemen memori tidak sempurna, dan memiliki tombol untuk diputar ketika ketidaksempurnaan itu muncul adalah hal yang baik.
Dan Pritts

62

Ya, mengosongkan cache akan membebaskan RAM, tetapi hal itu menyebabkan kernel untuk mencari file di disk daripada di cache yang dapat menyebabkan masalah kinerja.

Biasanya kernel akan menghapus cache ketika RAM yang tersedia habis. Ini sering menulis konten yang kotor ke disk menggunakan pdflush.


20
+1 untuk menjelaskan mengapa itu ide yang buruk.
Ogre Psalm33

35

Alasan untuk menjatuhkan cache seperti ini adalah untuk membandingkan kinerja disk, dan merupakan satu-satunya alasan itu ada.

Saat menjalankan benchmark I / O-intensif, Anda ingin memastikan bahwa berbagai pengaturan yang Anda coba semuanya benar-benar melakukan disk I / O, sehingga Linux memungkinkan Anda untuk menjatuhkan cache daripada melakukan reboot penuh.

Mengutip dari dokumentasi :

File ini bukan sarana untuk mengontrol pertumbuhan berbagai cache kernel (inode, dentries, pagecache, dll ...) Objek-objek ini secara otomatis diperoleh kembali oleh kernel ketika memori diperlukan di tempat lain pada sistem.

Penggunaan file ini dapat menyebabkan masalah kinerja. Karena membuang objek yang di-cache, mungkin diperlukan I / O dan CPU dalam jumlah yang cukup besar untuk membuat ulang objek yang dijatuhkan, terutama jika mereka sedang digunakan dalam jumlah besar. Karena itu, penggunaan di luar lingkungan pengujian atau debug tidak disarankan.


Tentu saja, tergantung pada apa yang Anda coba lakukan, bahkan reboot penuh mungkin tidak cukup menghapus cache disk.
CVn

1
"objek-objek ini secara otomatis direklamasi oleh kernel ketika memori dibutuhkan" adalah tujuan desain tetapi mungkin tidak selalu merupakan perilaku aktual.
Dan Pritts

@DanPritts Apa yang membuat Anda berpikir itu tidak benar?
Joe

2
Kasus yang jelas adalah ketika Anda ingin menghapus RAM untuk memungkinkan alokasi lebih banyak (non-trnsparent) hugepage; kasus lain adalah transparan hugepage pengumpulan sampah jeda bug (lihat jawaban saya / komentar di tempat lain tentang pertanyaan ini). Tetapi komentar saya ditujukan untuk kasus umum. Terkadang orang yang mengoperasikan sistem lebih tahu daripada orang yang merancang / mengimplementasikannya. Seringkali, tidak - itulah yang ingin dilindungi oleh komentar mereka. Saya hanya senang bahwa
Dan Pritts

26

Ide dasar di sini mungkin tidak terlalu buruk (hanya sangat naif dan menyesatkan): Mungkin ada file yang di-cache, yang sangat tidak mungkin diakses dalam waktu dekat, misalnya file log. Ini ram "memakan", yang nantinya harus dibebaskan ketika diperlukan oleh OS dengan satu atau lain cara.

Bergantung pada pengaturan swappiness Anda, pola akses file, pola alokasi memori dan banyak hal yang tidak dapat diprediksi, mungkin terjadi ketika Anda tidak membebaskan cache ini, mereka kemudian akan dipaksa untuk digunakan kembali, yang membutuhkan waktu sedikit lebih lama daripada mengalokasikan memori dari kumpulan memori yang tidak digunakan. Dalam kasus terburuk pengaturan swappiness dari linux akan menyebabkan memori program untuk ditukar, karena linux berpikir file-file itu mungkin lebih mungkin digunakan dalam waktu dekat daripada memori program.

Di lingkungan saya, linux menebak cukup sering salah, dan pada awal sebagian besar bursa saham eropa (sekitar 0900 waktu setempat) server akan mulai melakukan hal-hal yang mereka lakukan hanya sekali sehari, perlu menukar memori yang sebelumnya ditukar karena menulis file log, mengompresi mereka, menyalinnya dll. sedang mengisi cache ke titik di mana hal-hal harus ditukar.

Tetapi apakah menjatuhkan cache solusi untuk masalah ini? jelas tidak. Apa yang menjadi solusinya di sini adalah memberi tahu linux apa yang tidak diketahuinya: bahwa file-file ini kemungkinan tidak akan digunakan lagi. Ini dapat dilakukan oleh aplikasi penulisan menggunakan hal-hal seperti posix_fadvise()atau menggunakan alat garis cmd seperti vmtouch(yang juga dapat digunakan untuk melihat hal-hal serta file cache).

Dengan begitu Anda dapat menghapus data yang tidak diperlukan lagi dari cache, dan menyimpan hal-hal yang harus di-cache, karena ketika Anda menjatuhkan semua cache, banyak hal harus dibaca ulang dari disk. Dan itu pada saat yang paling buruk: ketika dibutuhkan; menyebabkan keterlambatan dalam aplikasi Anda yang terlihat dan seringkali tidak dapat diterima.

Yang harus Anda miliki adalah sistem yang memantau pola penggunaan memori Anda (misalnya jika ada pertukaran) dan kemudian menganalisisnya, dan bertindak sesuai dengan itu. Solusinya mungkin dengan mengusir beberapa file besar di akhir hari menggunakan vtouch; mungkin juga menambahkan lebih banyak ram karena penggunaan puncak harian server hanya itu.


Semua aplikasi di server saya berjalan di nohup. Mungkin nohup.out sedang di-cache dan memakan memori?
ivcode

@ivcode: Ini bisa menjadi alasan, periksa seberapa besar nohup.out. Mungkin menggunakan vmtouch untuk mencari tahu berapa banyak yang di-cache.
PlasmaHH

Saya memiliki tugas cron cat /dev/null > path/nohup.outdalam setiap 15 menit karena nohup.out berkembang pesat. Mungkin linux sedang melakukan caching nohup.out bahkan jika saya menghapusnya
ivcode

5
@ivcode Jika Anda tidak memerlukan output dari nohupAnda harus mengarahkannya kembali /dev/null. Sepertinya Anda memiliki beberapa sysadmin yang sangat tidak berpengalaman yang bekerja pada sistem Anda di beberapa titik. Lihat stackoverflow.com/questions/10408816/... untuk cara mengarahkan nohupoutput ke/dev/null
David Wilkins

meskipun nohup.out dihapus dalam interval 15 menit, jika proses aplikasi terbunuh karena suatu alasan, nohup.out akan secara otomatis dicadangkan dari skrip lain. saya mencoba vmtouch. itu memang alat yang sangat bagus
ivcode

16

Saya telah melihat drop cache berguna ketika memulai banyak mesin virtual. Atau apa pun yang menggunakan Halaman Besar seperti beberapa server database.

Halaman-halaman besar di Linux sering kali perlu defrag RAM untuk menemukan 2MB RAM fisik yang berdekatan untuk dimasukkan ke dalam halaman. Membebaskan semua cache file membuat proses ini sangat mudah.

Tapi saya setuju dengan sebagian besar jawaban lain di bahwa tidak ada alasan umum yang baik untuk menjatuhkan file cache setiap malam.


1
Saya memilih untuk menunjukkan prasangka urutan kedua adalah respons untuk menjatuhkan cache.
Noah Spurrier

1
Juga, dalam aplikasi HPC pada node memori tinggi (1Tb), membaca dalam beberapa file besar menghasilkan sejumlah besar memori yang di-cache. Karena banyak aplikasi HPC menjalankan malloc dengan berat ratusan GB, sistem ini dapat macet selama berjam-jam karena proses migrasi memindahkan potongan-potongan kecil memori yang terfragmentasi tanpa hasil di seluruh NUMA node begitu sistem mencapai "cache" memori cache. Lebih buruk lagi, tidak ada yang dapat Anda lakukan di userland untuk membebaskan cache kecuali menipu sistem untuk mengalokasikan semua blok kecil 2MB yang dapat dilepaskan secara bersamaan, membiarkan defrag yang diprogram dan aplikasi berjalan normal.
user1649948

+1 Perintah untuk membuat halaman besar ( sysctl -w vm.nr_hugepages=...) menolak untuk bekerja kecuali jika saya pertama kali menjatuhkan cache (Arch linux).
Aleksandr Dubinsky

8

Ada kemungkinan bahwa ini dilembagakan sebagai cara untuk menstabilkan sistem ketika tidak ada orang dengan keterampilan atau pengalaman untuk benar-benar menemukan masalah.

Membebaskan sumber daya

Menjatuhkan cache pada dasarnya akan membebaskan beberapa sumber daya, tetapi ini memiliki efek samping membuat sistem benar-benar bekerja lebih keras untuk melakukan apa yang ingin dilakukan. Jika sistem bertukar (mencoba membaca dan menulis dari partisi swap disk lebih cepat daripada yang sebenarnya mampu) maka menjatuhkan cache secara berkala dapat meringankan gejalanya , tetapi tidak melakukan apa pun untuk menyembuhkan penyebabnya .

Apa yang memakan memori?

Anda harus menentukan apa yang menyebabkan banyak konsumsi memori yang membuat menjatuhkan cache sepertinya berfungsi. Hal ini dapat disebabkan oleh sejumlah proses server yang tidak dikonfigurasi dengan benar atau hanya salah digunakan. Misalnya, pada satu server saya menyaksikan pemanfaatan memori maks ketika sebuah situs web Magento mencapai sejumlah pengunjung dalam interval 15 menit. Ini akhirnya disebabkan oleh Apache yang dikonfigurasi untuk memungkinkan terlalu banyak proses untuk dijalankan secara bersamaan. Terlalu banyak proses, menggunakan banyak memori (Magento kadang-kadang beast) = bertukar.

Intinya

Jangan hanya berasumsi bahwa itu adalah sesuatu yang perlu. Jadilah proaktif dalam mencari tahu mengapa itu ada, punya nyali untuk menonaktifkannya jika orang lain mengatakan itu salah, dan amati sistemnya - pelajari apa masalah sebenarnya dan perbaiki.


4

Linux / m68k sebenarnya memiliki bug kernel yang menyebabkan kswapd menjadi gila dan memakan CPU 100% (50% jika ada beberapa tugas lain yang terikat CPU, seperti autobuilder paket biner Debian - vulgo buildd - sudah berjalan), yang dapat (kebanyakan dari waktu; tidak selalu) dikurangi dengan menjalankan perintah khusus ini setiap beberapa jam.

Yang sedang berkata ... server Anda kemungkinan besar bukan sistem m68k (Atari, Amiga, Classic Macintosh, VME, Q40 / Q60, Sun3) ;-)

Dalam hal ini, orang yang membuat antrian mengikuti beberapa saran yang dipertanyakan atau, paling banter, ketinggalan jaman, atau mendapat ide tentang bagaimana RAM seharusnya digunakan secara salah (pemikiran modern memang mengatakan "RAM gratis adalah RAM yang terbuang" dan menyarankan caching) , atau "menemukan" bahwa ini "memperbaiki" [sic!] masalah lain di tempat lain (dan terlalu malas untuk mencari perbaikan yang tepat).


"bug kernel yang menyebabkan kswapd menjadi gila" - Bug mana ini?
Ben

@Ben lihat utas ini (pesan ini dan beberapa tindak lanjut, salah satunya termasuk menebak dari mana asalnya)
mirabilos

1
Saya mengalami masalah yang serupa (walaupun ini x86_64) dan satu-satunya solusi saat ini adalah dengan menjatuhkan cache serverfault.com/questions/740790/…
Fernando

2
@Fernando Saya punya "drop caches" cronjob di kotak m68k juga ☹
mirabilos

3

Salah satu alasannya mungkin situs tersebut menjalankan semacam pemantauan, yang memeriksa jumlah ram gratis dan mengirimkan peringatan kepada administrator ketika ram gratis turun di bawah persentase tertentu. Jika alat pemantauan itu cukup bodoh untuk tidak memasukkan cache dalam perhitungan ram gratis, itu mungkin mengirim peringatan palsu; mengosongkan cache secara teratur dapat menekan peringatan ini sementara masih memungkinkan alat untuk memperhatikan ketika ram "nyata" semakin rendah.

Tentu saja, dalam situasi seperti ini, solusi sebenarnya adalah memodifikasi alat pemantauan untuk memasukkan cache dalam perhitungan ram gratis; membersihkan cache hanyalah solusi, dan yang buruk juga, karena cache akan mengisi ulang dengan cepat ketika proses mengakses disk.

Jadi, bahkan jika asumsi saya benar, pembersihan cache bukanlah sesuatu yang masuk akal, itu lebih merupakan solusi oleh seseorang yang tidak cukup kompeten untuk memperbaiki masalah utama.


3

Saya dapat memikirkan satu alasan yang masuk akal untuk melakukan ini dalam pekerjaan cron malam.

Pada sistem yang besar, mungkin berguna untuk menjatuhkan cache secara berkala sehingga Anda dapat menghapus fragmentasi memori.

Dukungan hugepage transparan kernel melakukan sapuan memori berkala untuk menyatukan halaman-halaman kecil ke dalam hugepage. Di bawah kondisi yang merosot, ini dapat menyebabkan sistem berhenti satu atau dua menit (pengalaman saya dengan ini adalah di RHEL6; mudah-mudahan membaik). Menjatuhkan cache bisa membuat penyapu hugepage memiliki ruang untuk bekerja.

Anda mungkin berpendapat bahwa ini adalah alasan yang bagus untuk menonaktifkan hugepage transparan; OTOH Anda mungkin percaya bahwa peningkatan kinerja keseluruhan dari hugepages transparan patut dimiliki, dan layak membayar harga kehilangan cache Anda sekali sehari.


Saya sudah memikirkan alasan lain mengapa Anda ingin melakukannya, meskipun tidak dalam pekerjaan cron. Tepat sebelum sistem virtualisasi memigrasi VM ke perangkat keras baru akan menjadi saat yang sangat baik untuk ini. Lebih sedikit konten memori untuk disalin ke host baru. Anda akhirnya harus membaca dari penyimpanan, sebagai gantinya, tentu saja, tetapi saya mungkin akan mengambil tradeoff itu.

Saya tidak tahu apakah ada perangkat lunak yang melakukan ini.


1
Apakah Anda punya sumber untuk ini? Ini kedengarannya seperti sesuatu yang harus diperbaiki di kernel jika itu masalah seperti itu.
gparent

3
Saya memiliki pengalaman pribadi dengan jeda dengan hugepage transparan. RHEL6, Dell R810, 4CPUs, 64GB RAM. Menonaktifkan hugepage transparan (ada file / proc untuk melakukannya) segera memperbaiki jeda. Saya tidak mencoba teknik drop cache saat itu; alih-alih, saya mengkonfigurasi ulang aplikasi java kami untuk menggunakan hugepage yang tidak transparan, dan membiarkan hugepage transparan dinonaktifkan. IIRC, kami melihat ke dalam situasi yang cukup untuk menyadari bahwa kami bukan satu-satunya orang yang terpengaruh, dan bahwa Red Hat tahu tentang masalah ini.
Dan Pritts

Halo Dan, saya menampilkan perilaku yang sama di server saya. Saya bekerja, dengan sejumlah besar data, dan ada penurunan kinerja drastis setelah 10+ perhitungan program python yang sama (x2-3 dari waktu perhitungan pertama). Jika saya melihatnya, ukuran cache memori sangat besar, 100 + GB. Dan jika saya menghapus cache memori ini, dan menjalankan kembali program saya, saya mendapatkan kembali waktu perhitungan awal saya. Apakah Anda memiliki dokumen atau info, untuk dibagikan tentang fenomena ini? Terima kasih.
Axel Borja

1
access.redhat.com/solutions/46111 menjelaskannya. Anda dapat menonaktifkan hugepage transparan untuk melihat apakah itu masalah dalam kasus Anda.
Dan Pritts

2

Hanya untuk menambahkan dua sen saya: Sistem tahu betul bahwa halaman-halaman memori ini adalah cache, dan akan turun sebanyak yang diperlukan ketika aplikasi meminta memori.

Pengaturan yang relevan adalah /proc/sys/vm/swappiness, yang memberi tahu kernel saat alokasi memori baru untuk memilih untuk menjatuhkan cache memori atau untuk menukar halaman memori yang dialokasikan "idle".


1

Pertanyaannya adalah dari tahun 2014, tetapi karena masalah ada sampai hari ini pada beberapa backend 6,8 ​​centos tersembunyi, mungkin masih berguna bagi seseorang.

https://github.com/zfsonlinux/zfs/issues/1548 menjelaskan masalah dengan zfs. Di sana, ruang disk tidak dibebaskan untuk file yang dihapus karena jika nfs digunakan di atas zfs inode file tidak dijatuhkan dari cache inode kernel.

Mengutip dari utas bug, behlendorf, 6 Januari 2015 menulis:

Spekulasi saat ini adalah bahwa untuk beberapa alasan server NFS menyimpan versi cache dari file handle. Sampai server NFS menjatuhkan file ini, ZFS tidak dapat memutuskan tautan file ini. Beberapa pengujian ringan telah menunjukkan bahwa menjatuhkan cache di server akan menyebabkan referensi ini dibatalkan (seperti pegangan file NFS) di titik mana ruang tersebut dibebaskan dengan benar. Tekanan memori juga dapat menyebabkannya jatuh.

yaitu gema 3 malam / / proc / sys / vm / drop_caches adalah perbaikan termudah untuk bug itu jika Anda tidak ingin memiliki waktu henti untuk merestrukturisasi zfs Anda.

Jadi mungkin bukan administrasi pengiriman barang, tetapi beberapa debugging yang bagus adalah alasannya.


0

Ini mungkin masuk akal pada sistem NUMA (akses memori tidak seragam), di mana, biasanya, setiap CPU (soket) dapat mengakses semua memori secara transparan tetapi memori sendiri dapat diakses lebih cepat daripada memori soket lainnya, terkait dengan aplikasi paralel HPC.

Banyak aplikasi paralel sederhana cenderung melakukan file I / O dari satu proses tunggal, sehingga meninggalkan sebagian besar memori pada satu NUMA node yang dialokasikan untuk cache disk, sedangkan pada node NUMA lainnya memori mungkin sebagian besar gratis. Dalam situasi ini, karena proses reclaiming cache di kernel Linux, sejauh yang saya tahu, masih belum sadar NUMA, proses yang berjalan pada node NUMA yang memiliki memori yang dialokasikan ke cache dipaksa untuk mengalokasikan memori pada node NUMA lainnya, selama ada RAM gratis di node lain, sehingga membunuh kinerja.

Namun, dalam sistem HPC, akan lebih bijaksana untuk membersihkan cache sebelum memulai pekerjaan pengguna baru, bukan pada waktu tertentu dengan cron.

Untuk aplikasi non paralel masalah ini tidak mungkin muncul.


0

Saat cache halaman Anda cukup besar (jauh lebih besar dari penggunaan swap Anda saat ini), dan swap in dan swap out terjadi secara bergantian, ini adalah saat Anda harus menjatuhkan cache. Saya telah melihat kasus di mana penggunaan memori meningkat di salah satu server database MariaDB saya yang menjalankan Ubuntu 16.04LTS, dan Linux hanya memilih untuk meningkatkan penggunaan swap daripada menghapus cache halaman yang tidak digunakan. Hugepage transparan sudah dinonaktifkan di sistem saya karena TokuDB mengharuskannya dinonaktifkan. Pokoknya mungkin itu bukan bug, tetapi linux masih melakukan perilaku ini cukup membingungkan bagi saya. Berbagai sumber menyatakan bahwa Linux akan menghapus halaman cache ketika aplikasi memintanya:

Tetapi kenyataannya tidak sesederhana itu. Solusinya adalah:

  1. Jalankan drop cache secara berkala
  2. Jalankan drop cache bila diperlukan (monitor menggunakan vmstat 1 untuk menukar kegiatan)
  3. Anjurkan linux untuk menghapus file tertentu dari cache (seperti file log apache) menggunakan utilitas seperti dd atau python-fadvise. Lihat https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Contoh dd run:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

Contoh python-fadvise:

pyadvise -d /var/log/apache2/access_log.1


-5

Saya memiliki mesin desktop dengan 16GB RAM yang berjalan pada kernel PAE. Setelah satu atau dua jam kinerja disk menurun secara dramatis hingga saya menjatuhkan cache sehingga saya cukup memasukkannya ke dalam cron. Saya tidak tahu apakah ini masalah dengan kernel PAE atau dengan implementasi cache yang sangat lambat jika ada banyak memori.


9
Ini adalah contoh utama administrasi sistem "kultus kargo": alih-alih menemukan dan menyelesaikan masalah, Anda hanya menutupi saja.
Michael Hampton

2
Terkadang solusi yang bijaksana adalah yang tepat. Mungkin saja menunda menyelesaikan masalah yang sebenarnya, atau mungkin solusi sebanyak yang diperlukan dalam situasi. Bahkan jika itu praktik buruk, itu masih bukan "pemujaan kargo." Ada sebab dan akibat yang ditunjukkan: drop cache dan kinerja disk meningkat.
Dan Pritts

1
Bagian dari definisi asli CCSA adalah kecenderungan untuk kesalahan korelasi sebab-akibat, dan di sinilah kita. Menutupi masalah dengan mengatasi entitas yang berkorelasi tetapi tidak kausal adalah pemecahan masalah yang suboptimal, yang merupakan konsep yang coba diperingatkan konsep CCSA.
underscore_d
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.