Terjemahan artikel telah disediakan pada malam permulaan kursus .
Secara berkala, di sana sini, persoalan timbul tentang cadangan Gluster mengenai penalaan kernel dan sama ada terdapat keperluan untuk ini.
Keperluan seperti itu jarang timbul. Pada kebanyakan beban kerja, kernel berfungsi dengan baik. Walaupun ada kelemahan. Dari segi sejarah, kernel Linux sanggup menggunakan banyak memori jika diberi peluang, termasuk untuk caching sebagai cara utama untuk meningkatkan prestasi.
Dalam kebanyakan kes, ini berfungsi dengan baik, tetapi di bawah beban berat ia boleh membawa kepada masalah.
Kami mempunyai banyak pengalaman dengan sistem intensif memori seperti CAD, EDA dan seumpamanya, yang mula perlahan di bawah beban berat. Dan kadangkala kami menghadapi masalah di Gluster. Selepas memerhati dengan teliti penggunaan memori dan kependaman cakera selama beberapa hari, kami mendapat beban yang berlebihan, iowait yang besar, ralat kernel (kernel oops), membeku, dsb.
Artikel ini adalah hasil daripada banyak eksperimen penalaan yang dilakukan dalam pelbagai situasi. Terima kasih kepada parameter ini, bukan sahaja responsif keseluruhan telah bertambah baik, tetapi kluster juga telah stabil dengan ketara.
Apabila ia datang kepada penalaan memori, perkara pertama yang perlu dilihat ialah subsistem memori maya (VM, memori maya), yang mempunyai sejumlah besar pilihan yang boleh mengelirukan anda.
vm.swappiness
Parameter vm.swappiness menentukan berapa banyak kernel menggunakan swap (swap, paging) berbanding RAM. Ia juga ditakrifkan dalam kod sumber sebagai "kecenderungan untuk mencuri memori yang dipetakan". Swappiness yang tinggi bermakna kernel akan lebih cenderung untuk menukar halaman yang dipetakan. Nilai swappiness yang rendah bermaksud sebaliknya: kernel akan kurang halaman daripada memori. Dengan kata lain, semakin tinggi nilainya vm.swappiness, semakin banyak sistem akan menggunakan swap.
Penggunaan pertukaran yang besar adalah tidak diingini, kerana blok data yang besar dimuatkan dan dipunggah ke dalam RAM. Ramai orang berpendapat bahawa nilai swapiness sepatutnya besar, tetapi dalam pengalaman saya, menetapkannya kepada "0" membawa kepada prestasi yang lebih baik.
Anda boleh membaca lebih lanjut di sini -
Tetapi, sekali lagi, tetapan ini harus digunakan dengan berhati-hati dan hanya selepas menguji aplikasi tertentu. Untuk aplikasi penstriman yang sangat dimuatkan, parameter ini harus ditetapkan kepada "0". Apabila ditukar kepada "0", responsif sistem bertambah baik.
vm.vfs_cache_pressure
Tetapan ini mengawal memori yang digunakan oleh kernel untuk direktori caching dan objek inode (dentry dan inode).
Dengan nilai lalai 100, kernel akan cuba membebaskan cache dentry dan inode secara "adil" kepada pagecache dan swapcache. Mengurangkan tekanan_cache_vfs menyebabkan kernel menyimpan cache gigi dan inod. Apabila nilainya ialah "0", kernel tidak akan sekali-kali mengepam cache dentri dan inod kerana tekanan memori, dan ini boleh membawa kepada ralat kehabisan memori dengan mudah. Meningkatkan vfs_cache_pressure melebihi 100 menyebabkan kernel mengutamakan pembilasan gigi dan inod.
Apabila menggunakan GlusterFS, ramai pengguna dengan jumlah data yang besar dan banyak fail kecil dengan mudah boleh menggunakan sejumlah besar RAM pada pelayan disebabkan oleh caching inode/dentry, yang boleh menyebabkan kemerosotan prestasi kerana kernel perlu memproses struktur data pada sistem dengan memori 40 GB. Menetapkan nilai ini melebihi 100 telah membantu ramai pengguna mencapai caching yang lebih adil dan responsif kernel yang lebih baik.
vm.nisbah_latar_kotor dan nisbah_kotor_vm
Parameter pertama (vm.dirty_background_ratio) menentukan peratusan ingatan dengan halaman kotor, selepas mencapai yang perlu untuk mula menyiram halaman kotor di latar belakang ke cakera. Sehingga peratusan ini dicapai, tiada halaman dibuang ke cakera. Dan apabila tetapan semula bermula, ia berjalan di latar belakang tanpa mengganggu proses berjalan.
Parameter kedua (vm.dirty_ratio) mentakrifkan peratusan memori yang boleh diduduki oleh halaman kotor sebelum denyar paksa bermula. Apabila ambang ini dicapai, semua proses menjadi segerak (disekat) dan tidak dibenarkan diteruskan sehingga I/O yang mereka minta benar-benar selesai dan data berada pada cakera. Dengan I/O yang berat, ini menyebabkan masalah kerana tiada caching data dan semua proses yang melakukan I/O disekat menunggu I/O. Ini membawa kepada sejumlah besar proses yang digantung, beban tinggi, ketidakstabilan sistem dan prestasi yang lemah.
Mengurangkan tetapan ini menyebabkan data dibuang ke cakera dengan lebih kerap dan tidak disimpan dalam RAM. Ini boleh membantu sistem berat memori di mana ia adalah perkara biasa untuk mengepam cache halaman 45-90 GB ke cakera, menghasilkan kependaman yang besar untuk aplikasi bahagian hadapan, mengurangkan tindak balas dan interaktiviti keseluruhan.
"1" > /proc/sys/vm/pagecache
Cache halaman ialah cache yang menyimpan data fail dan program boleh laku, iaitu halaman dengan kandungan sebenar fail atau peranti sekat. Cache ini digunakan untuk mengurangkan bilangan bacaan cakera. Nilai "1" bermakna 1% daripada RAM digunakan untuk cache dan akan terdapat lebih banyak bacaan daripada cakera daripada daripada RAM. Ia tidak perlu menukar tetapan ini, tetapi jika anda paranoid tentang mengawal cache halaman, anda boleh menggunakannya.
"tarikh akhir" > /sys/block/sdc/queue/scheduler
Penjadual I/O ialah komponen kernel Linux yang mengendalikan baris gilir baca dan tulis. Secara teori, lebih baik menggunakan "noop" untuk pengawal RAID pintar, kerana Linux tidak mengetahui apa-apa tentang geometri fizikal cakera, jadi lebih cekap untuk membiarkan pengawal, yang mengetahui geometri cakera dengan baik, memproses permintaan secepat mungkin. mungkin. Tetapi nampaknya "tarikh akhir" meningkatkan prestasi. Anda boleh membaca lebih lanjut mengenai penjadual dalam dokumentasi kod sumber kernel Linux: linux/Documentation/block/*osched.txt. Dan juga saya telah melihat peningkatan dalam daya baca semasa operasi bercampur (banyak menulis).
"256" > /sys/block/sdc/queue/nr_requests
Bilangan permintaan I/O dalam penimbal sebelum ia dihantar kepada penjadual. Saiz baris gilir dalaman sesetengah pengawal (queue_depth) lebih besar daripada nr_requests penjadual I/O, jadi penjadual I/O mempunyai peluang kecil untuk mengutamakan dan menggabungkan permintaan dengan betul. Untuk penjadual tarikh akhir dan CFQ, adalah lebih baik apabila nr_requests adalah 2 kali baris gilir dalaman pengawal. Permintaan penggabungan dan penyusunan semula membantu penjadual menjadi lebih responsif di bawah beban berat.
echo "16" > /proc/sys/vm/page-cluster
Parameter kelompok halaman mengawal bilangan halaman yang ditulis kepada swap pada satu masa. Dalam contoh di atas, nilai ditetapkan kepada "16" mengikut saiz jalur RAID 64 KB. Ia tidak masuk akal dengan swappiness = 0, tetapi jika anda menetapkan swappiness kepada 10 atau 20 maka menggunakan nilai ini akan membantu anda apabila saiz jalur RAID ialah 64K.
blockdev --setra 4096 /dev/<nama dev> (-sdb, hdc atau dev_mapper)
Tetapan peranti blok lalai untuk kebanyakan pengawal RAID selalunya menghasilkan prestasi yang teruk. Menambah pilihan di atas menyediakan baca ke hadapan untuk sektor 4096 * 512-bait. Sekurang-kurangnya, untuk operasi penstriman, kelajuan ditingkatkan dengan mengisi cache cakera pada cip dengan baca ke hadapan semasa tempoh yang digunakan oleh kernel untuk menyediakan I/O. Cache boleh mengandungi data yang akan diminta pada bacaan seterusnya. Terlalu banyak prefetch boleh membunuh I/O rawak untuk fail besar jika ia menggunakan masa cakera yang berpotensi berguna atau memuatkan data di luar cache.
Di bawah ialah beberapa lagi pengesyoran pada peringkat sistem fail. Tetapi mereka belum diuji lagi. Pastikan sistem fail anda mengetahui saiz jalur dan bilangan cakera dalam tatasusunan. Sebagai contoh, ini ialah susunan serbuan jalur 5K yang terdiri daripada enam cakera (sebenarnya lima, kerana satu cakera digunakan untuk pariti). Cadangan ini adalah berdasarkan andaian teori dan disusun daripada pelbagai 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 fail besar, pertimbangkan untuk meningkatkan saiz jalur yang disenaraikan di atas.
PERHATIAN Semua yang diterangkan di atas adalah sangat subjektif untuk beberapa jenis aplikasi. Artikel ini tidak menjamin sebarang penambahbaikan tanpa ujian pengguna terlebih dahulu terhadap aplikasi berkaitan. Ia hanya boleh digunakan jika perlu untuk meningkatkan responsif keseluruhan sistem, atau jika ia menyelesaikan masalah semasa.
Bahan tambahan:
Baca lagi
Sumber: www.habr.com