Mengapa menjatuhkan cache di Linux?

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?

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

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.

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.

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.

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.

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.

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).

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.

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.

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".

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.

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.

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:

• https://www.linuxatemyram.com/
• https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics

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

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.