Terjemahan artikel disiapkan pada malam dimulainya kursus .
Secara berkala, di sana-sini, muncul pertanyaan tentang rekomendasi Gluster terkait penyetelan kernel dan apakah ini perlu.
Kebutuhan seperti itu jarang muncul. Pada sebagian besar beban kerja, kinerja kernel sangat baik. Meskipun ada sisi negatifnya. Secara historis, kernel Linux rela memakan banyak memori jika diberi kesempatan, termasuk untuk caching sebagai cara utama untuk meningkatkan kinerja.
Dalam kebanyakan kasus, ini berfungsi dengan baik, tetapi di bawah beban berat dapat menyebabkan masalah.
Kami memiliki banyak pengalaman dengan sistem intensif memori seperti CAD, EDA dan sejenisnya, yang mulai melambat di bawah beban berat. Dan terkadang kami mengalami masalah di Gluster. Setelah dengan hati-hati mengamati penggunaan memori dan latensi disk selama beberapa hari, kami mendapatkan kelebihan beban, iowait besar, kesalahan kernel (kernel oops), macet, dll.
Artikel ini adalah hasil dari banyak eksperimen penyetelan yang dilakukan dalam berbagai situasi. Berkat parameter ini, tidak hanya responsivitas keseluruhan yang meningkat, tetapi cluster juga menjadi stabil secara signifikan.
Dalam hal penyetelan memori, hal pertama yang harus dilihat adalah subsistem memori virtual (VM, memori virtual), yang memiliki banyak opsi yang dapat membingungkan Anda.
vm.swappiness
Parameter vm.swappiness menentukan seberapa banyak kernel menggunakan swap (swap, paging) dibandingkan dengan RAM. Itu juga didefinisikan dalam kode sumber sebagai "kecenderungan untuk mencuri memori yang dipetakan". Nilai tukar yang tinggi berarti kernel akan lebih cenderung untuk menukar halaman yang dipetakan. Nilai swappiness yang rendah berarti sebaliknya: kernel akan lebih sedikit halaman dari memori. Dengan kata lain, semakin tinggi nilainya vm.swappiness, semakin sistem akan menggunakan swap.
Penggunaan swapping yang besar tidak diinginkan, karena blok data yang sangat besar dimuat dan diturunkan ke dalam RAM. Banyak orang berpendapat bahwa nilai swapiness harus besar, tetapi menurut pengalaman saya, menyetelnya ke "0" menghasilkan kinerja yang lebih baik.
Anda dapat membaca lebih lanjut di sini -
Namun, sekali lagi, pengaturan ini harus diterapkan dengan hati-hati dan hanya setelah menguji aplikasi tertentu. Untuk aplikasi streaming yang sarat muatan, parameter ini harus disetel ke "0". Saat diubah menjadi "0", respons sistem meningkat.
vm.vfs_cache_pressure
Pengaturan ini mengontrol memori yang dikonsumsi oleh kernel untuk menyimpan direktori dan objek inode (dentry dan inode).
Dengan nilai default 100, kernel akan mencoba membebaskan cache dentry dan inode secara "adil" ke pagecache dan swapcache. Penurunan vfs_cache_pressure menyebabkan kernel menyimpan cache dentry dan inode. Ketika nilainya "0", kernel tidak akan pernah menghapus cache dentry dan inode karena tekanan memori, dan ini dapat dengan mudah menyebabkan kesalahan kehabisan memori. Meningkatkan vfs_cache_pressure di atas 100 menyebabkan kernel memprioritaskan dentry dan pembilasan inode.
Saat menggunakan GlusterFS, banyak pengguna dengan data dalam jumlah besar dan banyak file kecil dapat dengan mudah menggunakan sejumlah besar RAM di server karena caching inode/dentry, yang dapat menyebabkan penurunan kinerja karena kernel harus memproses struktur data pada sistem dengan memori 40 GB. Menetapkan nilai ini di atas 100 telah membantu banyak pengguna mencapai caching yang lebih adil dan respons kernel yang lebih baik.
vm.dirty_background_ratio dan vm.dirty_ratio
Parameter pertama (vm.dirty_background_ratio) menentukan persentase memori dengan halaman kotor, setelah itu perlu untuk mulai membilas halaman kotor di latar belakang ke disk. Hingga persentase ini tercapai, tidak ada halaman yang dipindahkan ke disk. Dan saat reset dimulai, ini berjalan di latar belakang tanpa mengganggu proses yang sedang berjalan.
Parameter kedua (vm.dirty_ratio) menentukan persentase memori yang dapat ditempati oleh halaman kotor sebelum flash paksa dimulai. Setelah ambang ini tercapai, semua proses menjadi sinkron (diblokir) dan tidak diizinkan untuk melanjutkan sampai I/O yang mereka minta benar-benar selesai dan datanya ada di disk. Dengan I/O yang berat, hal ini menimbulkan masalah karena tidak ada caching data dan semua proses yang melakukan I/O diblokir menunggu I/O. Hal ini menyebabkan sejumlah besar proses macet, beban tinggi, ketidakstabilan sistem, dan kinerja yang buruk.
Mengurangi pengaturan ini menyebabkan data lebih sering dibuang ke disk dan tidak disimpan dalam RAM. Ini dapat membantu sistem dengan banyak memori yang baik-baik saja dengan membilas cache halaman 45-90 GB ke disk, menghasilkan latensi yang sangat besar untuk aplikasi front-end, mengurangi responsivitas dan interaktivitas secara keseluruhan.
"1" > /proc/sys/vm/pagecache
Cache halaman adalah cache yang menyimpan data file dan program yang dapat dieksekusi, yaitu halaman dengan konten sebenarnya dari file atau memblokir perangkat. Cache ini digunakan untuk mengurangi jumlah pembacaan disk. Nilai "1" berarti 1% RAM digunakan untuk cache dan akan ada lebih banyak pembacaan dari disk daripada dari RAM. Tidak perlu mengubah pengaturan ini, tetapi jika Anda paranoid tentang mengontrol cache halaman, Anda dapat menggunakannya.
"tenggat waktu" > /sys/block/sdc/queue/scheduler
Penjadwal I/O adalah komponen kernel Linux yang menangani antrean baca dan tulis. Secara teori, lebih baik menggunakan "noop" untuk pengontrol RAID pintar, karena Linux tidak tahu apa-apa tentang geometri fisik disk, jadi lebih efisien membiarkan pengontrol, yang mengetahui geometri disk dengan baik, memproses permintaan secepat mungkin. Tapi sepertinya "batas waktu" meningkatkan kinerja. Anda dapat membaca lebih lanjut tentang penjadwal dalam dokumentasi kode sumber kernel Linux: linux/Documentation/block/*osched.txt. Dan juga saya telah melihat peningkatan throughput baca selama operasi campuran (banyak operasi tulis).
"256" > /sys/block/sdc/queue/nr_requests
Jumlah permintaan I/O dalam buffer sebelum diteruskan ke penjadwal. Beberapa ukuran antrean internal pengontrol (queue_depth) lebih besar daripada nr_requests penjadwal I/O, sehingga penjadwal I/O memiliki sedikit peluang untuk memprioritaskan dan menggabungkan permintaan dengan benar. Untuk penjadwal tenggat waktu dan CFQ, lebih baik jika nr_requests adalah 2 kali antrean internal pengontrol. Menggabungkan dan menyusun ulang permintaan membantu penjadwal menjadi lebih responsif di bawah beban berat.
echo "16" > /proc/sys/vm/page-cluster
Parameter page-cluster mengontrol jumlah halaman yang ditulis ke swap pada satu waktu. Pada contoh di atas, nilainya disetel ke "16" sesuai dengan ukuran strip RAID 64 KB. Tidak masuk akal dengan swappiness = 0, tetapi jika Anda menyetel swappiness ke 10 atau 20, maka menggunakan nilai ini akan membantu Anda saat ukuran strip RAID adalah 64K.
blockdev --setra 4096 /dev/<nama pengembang> (-sdb, hdc atau dev_mapper)
Pengaturan perangkat blok default untuk banyak pengontrol RAID sering kali menghasilkan kinerja yang buruk. Menambahkan opsi di atas menyiapkan read-ahead untuk sektor 4096 * 512-byte. Paling tidak, untuk operasi streaming, kecepatan ditingkatkan dengan mengisi cache disk on-chip dengan read-ahead selama periode yang digunakan oleh kernel untuk mempersiapkan I/O. Cache dapat berisi data yang akan diminta pada pembacaan berikutnya. Terlalu banyak prefetch dapat mematikan I/O acak untuk file besar jika menggunakan waktu disk yang berpotensi berguna atau memuat data di luar cache.
Di bawah ini adalah beberapa rekomendasi lagi di tingkat sistem file. Tapi mereka belum diuji. Pastikan sistem file Anda mengetahui ukuran garis dan jumlah disk dalam larik. Misalnya, ini adalah array 5K stripe raid64 yang terdiri dari enam disk (sebenarnya lima, karena satu disk digunakan untuk paritas). Rekomendasi ini didasarkan pada asumsi teoretis dan disusun dari berbagai blog/artikel oleh pakar RAID.
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))Untuk file besar, pertimbangkan untuk menambah ukuran garis yang tercantum di atas.
PERINGATAN! Semua yang dijelaskan di atas sangat subjektif untuk beberapa jenis aplikasi. Artikel ini tidak menjamin peningkatan apa pun tanpa pengujian pengguna sebelumnya dari masing-masing aplikasi. Ini hanya boleh digunakan jika diperlukan untuk meningkatkan daya tanggap sistem secara keseluruhan, atau jika memecahkan masalah saat ini.
Bahan tambahan:
Baca selengkapnya
Sumber: www.habr.com