Bisakah saya mengkonfigurasi sistem Linux saya untuk caching sistem file yang lebih agresif?


119

Saya tidak khawatir tentang penggunaan RAM (seperti yang saya punya cukup) atau tentang kehilangan data jika terjadi kecelakaan yang tidak disengaja (karena kekuatan saya didukung, sistem ini dapat diandalkan dan data tidak kritis). Tetapi saya melakukan banyak pemrosesan file dan dapat menggunakan beberapa peningkatan kinerja.

Itu sebabnya saya ingin mengatur sistem agar menggunakan lebih banyak RAM untuk membaca dan menulis caching sistem file, untuk mengambil file secara agresif (mis. Baca-depan seluruh file yang diakses oleh aplikasi jika file berukuran waras atau setidaknya baca-depan sebagian besar itu sebaliknya) dan untuk menyiram menulis buffer kurang sering. Bagaimana cara mencapai ini (mungkinkah)?

Saya menggunakan sistem file ext3 dan ntfs (saya menggunakan ntfs banyak!) Dengan XUbuntu 11.10 x86.


6
Jika Anda memiliki banyak RAM, sangat peduli dengan kinerja dan tidak peduli dengan kehilangan data, cukup salin semua data Anda ke disk RAM dan sajikan dari sana, buang semua pembaruan saat terjadi crash / shutdown. Jika itu tidak bekerja untuk Anda, Anda mungkin harus memenuhi syarat "cukup" untuk RAM atau seberapa penting data tidak.
James Youngman

1
@Nils, komputer adalah laptop, jadi, saya percaya, pengontrolnya cukup biasa.
Ivan

1
Salah satu cara untuk meningkatkan kinerja banyak adalah dengan melewatkan daya tahan data. Cukup nonaktifkan sinkronisasi ke disk bahkan jika beberapa aplikasi meminta sinkronisasi. Ini akan menyebabkan kehilangan data jika perangkat penyimpanan Anda pernah mengalami kehilangan listrik. Jika Anda tetap ingin melakukannya, cukup jalankan sudo mount -o ro,nobarrier /path/to/mountpointatau sesuaikan /etc/fstabuntuk memasukkan nobarriersemua sistem file yang bersedia Anda korbankan untuk peningkatan kinerja. Namun, jika perangkat penyimpanan Anda memiliki baterai internal seperti Intel 320 SSD series, menggunakan nobarriertidak menyebabkan kehilangan data.
Mikko Rantalainen

1
Penggunaan nobarrier tidak lagi direkomendasikan di Red Hat Enterprise Linux 6 karena dampak kinerja negatif dari hambatan penulisan dapat diabaikan (sekitar 3%). Manfaat hambatan penulisan biasanya lebih besar daripada manfaat kinerja dari menonaktifkannya. Selain itu, opsi nobarrier tidak boleh digunakan pada penyimpanan yang dikonfigurasi pada mesin virtual. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
Ivailo Bardarov

1
Dua poin - 1) Ada distro linux berdasarkan Debian atau Ubuntu, seperti Puppy Linux dan AntiX Linux, dan banyak lainnya yang menempatkan seluruh sistem operasi di partisi ramdisk berlapis (yaitu AUFS atau overlayfs) dan mengelolanya secara transparan. Sangat cepat! - 2) Kami menemukan dalam desain dunia nyata dari sistem yang sangat besar yang melemparkan lebih banyak cache dapat MENGURANGI KINERJA. Saat kecepatan penyimpanan meningkat (yaitu SSD), ukuran cache optimal yang dibutuhkan berkurang. Tidak ada cara untuk mengetahui ukuran itu tanpa eksperimen pada sistem khusus Anda. Jika kenaikan tidak berhasil, coba kurangi.
DocSalvager

Jawaban:


107

Meningkatkan kinerja cache disk secara umum lebih dari sekedar meningkatkan ukuran cache sistem file kecuali jika seluruh sistem Anda cocok dengan RAM dalam hal ini Anda harus menggunakan drive RAM ( tmpfsbagus karena memungkinkan jatuh kembali ke disk jika Anda membutuhkan RAM dalam beberapa kasus) untuk penyimpanan runtime (dan mungkin skrip initrd untuk menyalin sistem dari penyimpanan ke drive RAM saat startup).

Anda tidak memberi tahu apakah perangkat penyimpanan Anda adalah SSD atau HDD. Inilah yang saya temukan bekerja untuk saya (dalam kasus saya sdaadalah HDD terpasang pada /homedan sdbSSD dipasang pada /).

Pertama-tama optimalkan bagian load-stuff-from-storage-to-cache:

Ini pengaturan saya untuk HDD (pastikan AHCI + NCQ diaktifkan di BIOS jika Anda memiliki matikan):

echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda

Perlu dicatat untuk kasus HDD tinggi fifo_expire_async(biasanya menulis) dan panjang slice_syncuntuk memungkinkan satu proses mendapatkan throughput tinggi (diatur slice_syncke angka yang lebih rendah jika Anda menekan situasi di mana beberapa proses menunggu beberapa data dari disk secara paralel). Itu slice_idleselalu merupakan kompromi untuk HDD tetapi pengaturannya di suatu tempat dalam kisaran 3-20 akan baik-baik saja tergantung pada penggunaan disk dan firmware disk. Saya lebih suka menargetkan nilai rendah tetapi pengaturan terlalu rendah akan merusak throughput Anda. The quantumpengaturan tampaknya mempengaruhi throughput yang banyak tapi mencoba untuk menjaga ini serendah mungkin untuk menjaga latency pada tingkat yang masuk akal. Pengaturan yang quantumterlalu rendah akan merusak throughput. Nilai dalam kisaran 3-8 tampaknya berfungsi baik dengan HDD. Latensi kasus terburuk untuk dibaca adalah ( quantum* slice_sync) + ( slice_async_rq*slice_async) ms jika saya memahami perilaku kernel dengan benar. Async sebagian besar digunakan oleh menulis dan karena Anda bersedia menunda menulis ke disk, atur keduanya slice_async_rqdan slice_asyncke angka yang sangat rendah. Namun, pengaturan slice_async_rqnilai yang terlalu rendah dapat menghentikan bacaan karena menulis tidak dapat ditunda setelah membaca lagi. Konfigurasi saya akan mencoba untuk menulis data ke disk paling setelah 10 detik setelah data telah diteruskan ke kernel tapi karena Anda dapat mentolerir hilangnya data pada penurunan daya juga mengatur fifo_expire_asyncuntuk 3600000memberitahu bahwa 1 jam apa-apa untuk penundaan ke disk. Tetap slice_asyncrendah, karena jika tidak, Anda bisa mendapatkan latensi baca yang tinggi.

The hdparmperintah diperlukan untuk mencegah AAM dari membunuh banyak kinerja yang AHCI + NCQ memungkinkan. Jika disk Anda mengeluarkan terlalu banyak suara, lewati saja ini.

Ini pengaturan saya untuk SSD (Intel 320 series):

echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync

Di sini perlu diperhatikan nilai rendah untuk pengaturan slice yang berbeda. Pengaturan paling penting untuk SSD adalah slice_idleyang harus diatur ke 0-1. Mengaturnya ke nol memindahkan semua keputusan pemesanan ke NCQ asli sementara mengaturnya ke 1 memungkinkan kernel untuk memesan permintaan (tetapi jika NCQ aktif, perangkat keras dapat menimpa pemesanan kernel sebagian). Uji kedua nilai untuk melihat apakah Anda dapat melihat perbedaannya. Untuk Intel 320 series, tampaknya pengaturan slide_idleuntuk 0memberikan throughput terbaik tetapi pengaturan untuk 1memberikan latensi keseluruhan terbaik (terendah).

Untuk informasi lebih lanjut tentang merdu ini, lihat http://www.linux-mag.com/id/7572/ .

Sekarang kita telah mengkonfigurasi kernel untuk memuat hal-hal dari disk ke cache dengan kinerja yang masuk akal, saatnya untuk menyesuaikan perilaku cache:

Menurut tolok ukur yang telah saya lakukan, saya tidak akan repot mengatur baca depan blockdevsama sekali. Pengaturan default kernel baik-baik saja.

Atur sistem untuk lebih suka menukar data file dengan kode aplikasi (ini tidak masalah jika Anda memiliki cukup RAM untuk menyimpan seluruh sistem file dan semua kode aplikasi dan semua memori virtual yang dialokasikan oleh aplikasi dalam RAM). Ini mengurangi latensi untuk bertukar di antara berbagai aplikasi melebihi latensi untuk mengakses file besar dari satu aplikasi:

echo 15 > /proc/sys/vm/swappiness

Jika Anda lebih suka menyimpan aplikasi hampir selalu dalam RAM, Anda dapat mengatur ini ke 1. Jika Anda menetapkan ini ke nol, kernel tidak akan bertukar sama sekali kecuali benar-benar diperlukan untuk menghindari OOM. Jika memori Anda terbatas dan bekerja dengan file besar (mis. Mengedit video HD), maka mungkin masuk akal untuk mengatur ini mendekati 100.

Saya saat ini (2017) lebih suka tidak memiliki swap sama sekali jika Anda memiliki cukup RAM. Tanpa swap biasanya akan kehilangan 200-1000 MB RAM pada mesin desktop yang berjalan lama. Saya rela berkorban banyak untuk menghindari latensi skenario terburuk (menukar kode aplikasi ketika RAM penuh). Dalam prakteknya, ini berarti saya lebih suka OOM Killer daripada bertukar. Jika Anda mengizinkan / perlu bertukar, Anda mungkin ingin menambah /proc/sys/vm/watermark_scale_factorjuga, untuk menghindari latensi. Saya akan menyarankan nilai antara 100 dan 500. Anda dapat mempertimbangkan pengaturan ini sebagai perdagangan penggunaan CPU untuk latensi swap yang lebih rendah. Default adalah 10 dan maksimum yang mungkin adalah 1000. Nilai yang lebih tinggi harus (sesuai dengan dokumentasi kernel ) menghasilkan penggunaan CPU yang lebih tinggi untuk kswapdproses dan latensi swapping keseluruhan yang lebih rendah.

Selanjutnya, beri tahu kernel untuk lebih memilih menjaga hierarki direktori dalam memori daripada konten file jika beberapa RAM perlu dibebaskan (sekali lagi, jika semuanya sesuai dalam RAM, pengaturan ini tidak melakukan apa-apa):

echo 10 > /proc/sys/vm/vfs_cache_pressure

Pengaturan vfs_cache_pressurenilai rendah masuk akal karena dalam kebanyakan kasus, kernel perlu mengetahui struktur direktori sebelum dapat menggunakan konten file dari cache dan membilas cache direktori terlalu cepat akan membuat cache file di samping tidak berharga. Pertimbangkan untuk turun ke 1 dengan pengaturan ini jika Anda memiliki banyak file kecil (sistem saya memiliki sekitar 150 ribu foto 10 megapiksel dan dianggap sebagai sistem "banyak file kecil"). Jangan pernah atur ke nol atau struktur direktori selalu disimpan dalam memori meskipun sistem kehabisan memori. Mengatur ini ke nilai besar masuk akal hanya jika Anda hanya memiliki beberapa file besar yang terus-menerus dibaca kembali (sekali lagi, pengeditan video HD tanpa cukup RAM akan menjadi contoh kasus). Dokumentasi kernel resmi mengatakan bahwa "

Pengecualian: jika Anda memiliki jumlah file dan direktori yang sangat besar dan Anda jarang menyentuh / membaca / membuat daftar semua file dengan pengaturan vfs_cache_pressurelebih tinggi dari 100 mungkin bijaksana. Ini hanya berlaku jika Anda tidak memiliki RAM yang cukup dan tidak dapat menyimpan seluruh struktur direktori dalam RAM dan masih memiliki cukup RAM untuk cache dan proses file normal (misalnya server file perusahaan dengan banyak konten arsip). Jika Anda merasa perlu menambah di vfs_cache_pressureatas 100, Anda berjalan tanpa RAM yang cukup. Meningkatkan vfs_cache_pressuremungkin membantu tetapi satu-satunya perbaikan nyata adalah untuk mendapatkan lebih banyak RAM. Setelah vfs_cache_pressureditetapkan ke angka tinggi mengorbankan kinerja rata-rata untuk memiliki kinerja yang lebih stabil secara keseluruhan (yaitu, Anda dapat menghindari perilaku kasus terburuk yang sangat buruk tetapi harus berurusan dengan kinerja keseluruhan yang lebih buruk).

Terakhir, suruh kernel untuk menggunakan hingga 99% dari RAM sebagai cache untuk menulis dan memerintahkan kernel untuk menggunakan hingga 50% dari RAM sebelum memperlambat proses penulisan (default for dirty_background_ratiois 10). Peringatan: Saya pribadi tidak akan melakukan ini tetapi Anda mengaku memiliki cukup RAM dan bersedia kehilangan data.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

Dan katakan bahwa penundaan penulisan 1 jam tidak masalah bahkan untuk mulai menulis hal-hal pada disk (sekali lagi, saya tidak akan melakukan ini):

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

Jika Anda meletakkan semua itu /etc/rc.localdan menyertakan berikut di akhir, semuanya akan ada dalam cache sesegera mungkin setelah boot (hanya lakukan ini jika filesystem Anda benar-benar sesuai dengan RAM):

(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

Atau alternatif yang sedikit lebih sederhana yang mungkin bekerja lebih baik (hanya cache /homedan /usr, lakukan ini hanya jika Anda benar /home- /usrbenar sesuai dengan RAM):

(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

3
Jawaban yang berpengetahuan luas dan keseluruhan jauh lebih baik daripada yang diterima! Yang ini diremehkan ... Saya kira kebanyakan orang hanya ingin instruksi sederhana tanpa repot-repot memahami apa yang sebenarnya mereka lakukan ...
Vladimir Panteleev

2
@ Phpdevpad: Selain itu, pertanyaannya mengatakan "Saya tidak peduli tentang penggunaan RAM [...]" - Saya tidak berpikir ada perangkat Maemo yang memenuhi syarat.
Mikko Rantalainen

1
Bukankah noop atau deadline scheduler yang lebih baik untuk SSD?
rep_movsd

1
@rep_movsd Saya hanya menggunakan drive Intel SSD tetapi setidaknya drive ini masih cukup lambat untuk memiliki kinerja keseluruhan yang lebih baik dengan penjadwal yang lebih cerdas seperti CFQ. Saya kira jika drive SSD Anda dapat menangani lebih dari 100K IOPS acak, menggunakan noop atau tenggat waktu akan masuk akal bahkan dengan CPU cepat. Dengan "CPU cepat", saya maksudkan sesuatu yang memiliki setidaknya beberapa inti 3GHz yang tersedia untuk IO saja.
Mikko Rantalainen

1
Anda juga dapat membaca tentang vm tunables ini dari vm kernel docs .
joeytwiddle

16

Pertama, saya TIDAK menyarankan Anda terus menggunakan NTFS, karena implementasi ntfs di Linux akan menimbulkan masalah kinerja dan keamanan kapan saja.

Ada beberapa hal yang dapat Anda lakukan:

  • gunakan beberapa fs baru seperti ext4ataubtrfs
  • coba ubah penjadwal io Anda, misalnya bfq
  • matikan swap
  • gunakan beberapa preloader otomatis seperti preload
  • gunakan sesuatu seperti systemdpreload saat booting
  • ... dan sesuatu yang lebih

Mungkin Anda ingin mencobanya :-)


1
Saya sudah pindah sepenuhnya dari NTFS ke ext4 sekali, meninggalkan satu-satunya partisi NTFS menjadi partisi sistem Windows. Tetapi ternyata banyak ketidaknyamanan bagi saya dan saya telah kembali ke NTFS sebagai partisi data utama (tempat saya menyimpan semua dokumen, unduhan, proyek, kode sumber, dll.) Saya. Saya tidak menyerah memikirkan kembali struktur partisi saya dan alur kerja saya (untuk menggunakan lebih sedikit Windows) tetapi sekarang menyerah NTFS sepertinya bukan pilihan yang realistis.
Ivan

Jika Anda harus menggunakan data Anda di dalam Windows juga, NTFS mungkin satu-satunya pilihan. (banyak pilihan lain yang tersedia jika Anda dapat menggunakan Windows Anda hanya sebagai VM di dalam linux)
Felix Yan

1
Ringkasan tentang apa yang seharusnya merupakan masalah NTFS akan bermanfaat.
underscore_d

2
NTFS di Linux cukup dapat diterima kecuali untuk kinerja. Mempertimbangkan bahwa pertanyaannya secara khusus tentang meningkatkan kinerja sistem file, NTFS harus menjadi hal pertama yang harus dilakukan.
Mikko Rantalainen

Meskipun btrfsbaru-baru ini dirancang sistem file, saya akan menghindari itu jika diperlukan kinerja. Kami telah menjalankan sistem yang identik dengan btrfsdan ext4sistem file dan ext4menang di dunia nyata dengan margin besar ( btrfstampaknya membutuhkan waktu CPU sekitar 4x ext4kebutuhan untuk tingkat kinerja yang sama dan menyebabkan lebih banyak operasi disk untuk satu perintah logis). Tergantung pada beban kerja, saya sarankan ext4, jfsatau xfsuntuk pekerjaan yang menuntut kinerja apa pun.
Mikko Rantalainen

8

Baca di depan:

Pada sistem 32 bit:

blockdev --setra 8388607 /dev/sda

Pada sistem 64 bit:

blockdev --setra 4294967295 /dev/sda

Tulis di belakang cache:

echo 100 > /proc/sys/vm/dirty_ratio

Ini akan menggunakan hingga 100% dari memori bebas Anda sebagai cache tulis.

Atau Anda bisa keluar semua dan menggunakan tmpfs. Ini hanya relevan jika Anda memiliki RAM yang cukup. Menempatkan ini dalam /etc/fstab. Ganti 100G dengan jumlah RAM fisik.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Kemudian:

mkdir /mnt/tmpfs; mount -a

Kemudian gunakan / mnt / tmpfs.


5
3GB atau 2TB readahead? Benarkah? Apakah Anda tahu apa yang dilakukan opsi ini?
Cobra_Fast

1
@Cobra_Fast Tahukah Anda apa artinya? Saya benar-benar tidak tahu dan saya tertarik sekarang.
syss

3
@syss pengaturan readahead disimpan sebagai jumlah "blok" memori, bukan byte atau bit. Ukuran satu blok ditentukan pada waktu kompilasi kernel (karena readahead-blok adalah blok memori) atau waktu pembuatan sistem file dalam beberapa kasus. Namun biasanya, 1 blok berisi 512 atau 4096 byte. Lihat linux.die.net/man/8/blockdev
Cobra_Fast

6

Anda dapat mengatur ukuran baca-depan dengan blockdev --setra sectors /dev/sda1, di mana sektor adalah ukuran yang Anda inginkan dalam sektor 512 byte.


2

Pengaturan pembunuh saya sangat sederhana dan sangat efektif:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

Penjelasan dari dokumentasi kernel :

vfs_cache_pressure

Mengontrol kecenderungan kernel untuk merebut kembali memori yang digunakan untuk caching objek direktori dan inode.

Pada nilai default vfs_cache_pressure = 100 kernel akan berusaha untuk mengklaim kembali gigi palsu dan inode pada tingkat "wajar" sehubungan dengan merebut kembali pagecache dan swapcache. Penurunan vfs_cache_pressure menyebabkan kernel lebih memilih untuk mempertahankan cache dentry dan inode. Ketika vfs_cache_pressure = 0, kernel tidak akan pernah mendapatkan kembali gigi palsu dan inode karena tekanan memori dan ini dapat dengan mudah menyebabkan kondisi kehabisan memori. Peningkatan vfs_cache_pressure di atas 100 menyebabkan kernel lebih memilih untuk merebut kembali gigi palsu dan inode.

vfs_cache_pressure pada tahun 2000 menyebabkan sebagian besar komputasi terjadi pada RAM dan penulisan disk yang sangat terlambat.


4
Pengaturan yang vfs_cache_pressureterlalu tinggi (saya anggap 2000terlalu tinggi) akan menyebabkan akses disk yang tidak perlu bahkan untuk hal-hal sederhana seperti daftar direktori yang harus dengan mudah disimpan dalam cache. Berapa banyak RAM yang Anda miliki dan apa yang Anda lakukan dengan sistem? Seperti yang saya tulis dalam jawaban saya, menggunakan nilai tinggi untuk pengaturan ini masuk akal untuk misalnya mengedit video HD dengan RAM terbatas.
Mikko Rantalainen

2
Perhatikan bahwa dokumentasi yang direferensikan berlanjut: " Meningkatkan vfs_cache_pressure secara signifikan melebihi 100 dapat memiliki dampak kinerja negatif. Kode reklamasi perlu mengambil berbagai kunci untuk menemukan direktori yang bebas dan objek inode. Dengan vfs_cache_pressure = 1000, ia akan mencari sepuluh kali lebih banyak objek yang dapat dibebaskan daripada di sana adalah."
Mikko Rantalainen

1

Tidak terkait dengan menulis caching, tetapi terkait dengan menulis:

  • Untuk sistem ext4, Anda bisa menonaktifkan penjurnalan sepenuhnya

    Ini akan mengurangi jumlah disk menulis untuk setiap pembaruan tertentu, tetapi mungkin meninggalkan sistem file tidak konsisten setelah shutdown yang tidak terduga, memerlukan fsck atau lebih buruk.

Untuk menghentikan pembacaan disk dari memicu disk menulis:

  • Mount dengan relatime atau opsi noatime

    Saat Anda membaca file, metadata "waktu terakhir diakses" untuk file itu biasanya diperbarui. The noatimepilihan akan menonaktifkan perilaku itu. Ini mengurangi penulisan disk yang tidak perlu, tetapi Anda tidak akan lagi memiliki metadata itu. Beberapa distribusi (misalnya Manjaro) telah mengadopsi ini sebagai default pada semua partisi (mungkin untuk menambah umur SSD model sebelumnya).

    relatimememperbarui waktu akses lebih jarang, sesuai dengan heuristik yang membantu mendukung aplikasi yang menggunakan atime. Ini adalah default pada Red Hat Enterprise Linux.

Pilihan lain:

  • Dalam komentar di atas, Mikko berbagi kemungkinan pemasangan dengan opsi nobarrier . Tapi Ivailo mengutip RedHat yang memperingatkannya. Seberapa buruk Anda menginginkan tambahan 3% itu?
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.