Dari waktu ke waktu, di sana-sini muncul pertanyaan tentang rekomendasi Gluster tentang penyetelan kernel dan apakah diperlukan untuk ini.
Kebutuhan seperti itu jarang terjadi. Kernel bekerja sangat baik pada sebagian besar beban kerja. Meski ada sisi negatifnya. Secara historis, kernel Linux dengan mudah menghabiskan banyak memori jika diberi kesempatan, termasuk untuk caching sebagai cara utama untuk meningkatkan kinerja.
Sebagian besar waktu ini berfungsi dengan baik, tetapi di bawah beban berat dapat menyebabkan masalah.
Kami memiliki banyak pengalaman dengan sistem yang menghabiskan banyak memori, seperti CAD, EDA dan sejenisnya, yang mulai melambat saat beban tinggi. Dan terkadang kami mengalami masalah dengan Gluster. Setelah mengamati dengan cermat memori yang digunakan dan latensi disk selama lebih dari satu hari, kami mendapatkan kelebihan beban, iowait besar, kesalahan kernel (oops kernel), macet, dll.
Artikel ini adalah hasil dari banyak eksperimen penyetelan yang dilakukan dalam berbagai situasi. Parameter ini tidak hanya meningkatkan responsivitas secara keseluruhan, tetapi juga secara signifikan menstabilkan kinerja cluster.
Dalam hal penyetelan memori, hal pertama yang harus dilihat adalah subsistem memori virtual (VM), yang memiliki banyak opsi yang dapat membingungkan Anda.
vm.swappiness
Parameter tersebut
vm.swappinessmenentukan seberapa banyak kernel menggunakan swap (swap) dibandingkan dengan memori utama. Dalam kode sumber, ini juga didefinisikan sebagai "kecenderungan untuk mencuri memori yang dipetakan" (kecenderungan untuk mencuri memori yang dipetakan). Nilai swappiness yang tinggi berarti kernel akan lebih rentan untuk membongkar halaman yang dirender. Nilai swappiness yang rendah berarti sebaliknya: kernel akan menukar lebih sedikit halaman dari memori. Dengan kata lain, semakin tinggi nilainya vm.swappiness, semakin banyak sistem akan bertukar.
Penggunaan swapping yang besar tidak diinginkan, karena blok data yang sangat besar dimuat dan dibongkar ke dalam RAM. Banyak yang berpendapat bahwa nilai swapiness harus tinggi, tetapi menurut pengalaman saya, menyetelnya ke "0" akan meningkatkan performa.
Anda dapat membaca detail lebih lanjut di sini -lwn.net/Articles/100978
Tapi sekali lagi, pengaturan ini harus diterapkan dengan hati-hati dan hanya setelah menguji aplikasi tertentu. Untuk aplikasi streaming dengan muatan tinggi, parameter ini harus disetel ke "0". Mengubah ke "0" meningkatkan daya tanggap sistem.
vm.vfs_cache_pressure
Parameter ini mengontrol memori yang dipakai oleh kernel untuk menyimpan objek direktori dan inode (dentry dan inode).
Dengan default 100, kernel akan mencoba melepaskan cache dentry dan inode secara adil ke pagecache dan swapcache. Penurunan vfs_cache_pressure menyebabkan kernel menyimpan cache dentry dan inode. Jika nilainya 0, kernel tidak akan pernah menghapus cache dentry dan inode karena tekanan memori yang tidak mencukupi, dan ini dapat dengan mudah menyebabkan kesalahan kehabisan memori. Meningkatkan vfs_cache_pressure di atas 100 menyebabkan kernel memprioritaskan dentry dan pembongkaran inode.
Dengan GlusterFS, banyak pengguna dengan data dalam jumlah besar dan banyak file kecil dapat dengan mudah menggunakan sejumlah besar RAM di server karena inode / dentry caching, yang dapat menyebabkan penurunan kinerja karena kernel harus memproses struktur data pada sistem dengan memori 40 GB ... Menyetel parameter ini di atas 100 telah membantu banyak pengguna mencapai caching yang lebih adil dan meningkatkan respons kernel.
vm.dirty_background_ratio dan vm.dirty_ratio
Parameter pertama (
vm.dirty_background_ratio) menentukan persentase memori dengan halaman kotor, setelah itu perlu untuk memulai pembersihan latar belakang halaman kotor ke disk. Sampai persentase ini tercapai, tidak ada halaman yang di-flush ke disk. Dan ketika reset dimulai, itu 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. Saat ambang batas ini tercapai, semua proses menjadi sinkron (diblokir) dan tidak diizinkan untuk terus berjalan hingga operasi I / O yang diminta benar-benar selesai dan data ada di disk. Dengan beban I / O yang tinggi, hal ini menyebabkan masalah, karena tidak ada cache data, dan semua proses I / O diblokir menunggu I / O. Hal ini menyebabkan sejumlah besar proses beku, beban tinggi, pengoperasian sistem tidak stabil, dan kinerja buruk.
Penurunan nilai parameter ini mengarah pada fakta bahwa data lebih sering di-flush ke disk dan tidak disimpan dalam RAM. Ini dapat membantu sistem dengan banyak memori, yang tidak masalah untuk mengosongkan cache halaman 45-90 GB, yang menghasilkan latensi yang sangat besar untuk aplikasi front-end, mengurangi respons dan interaktivitas secara keseluruhan.
"1"> / proc / sys / vm / pagecache
Cache halaman adalah cache yang menyimpan data untuk file dan program yang dapat dijalankan, yaitu halaman-halaman dengan konten sebenarnya dari file atau perangkat blokir. Cache ini digunakan untuk mengurangi jumlah pembacaan disk. Nilai "1" berarti cache menggunakan 1% RAM dan akan ada lebih banyak pembacaan dari disk daripada dari RAM. Parameter ini tidak perlu diubah, tetapi jika Anda paranoid tentang kontrol atas cache halaman, Anda dapat menggunakannya.
Tenggat waktu> / sys / block / sdc / queue / scheduler
Penjadwal I / O adalah komponen kernel Linux yang menangani antrian baca dan tulis. Secara teori, lebih baik menggunakan "noop" untuk pengontrol RAID yang cerdas, karena Linux tidak mengetahui apa pun tentang geometri fisik disk, jadi akan lebih efisien untuk mengizinkan pengontrol dengan pengetahuan yang baik tentang geometri disk memproses permintaan secepat mungkin. Namun tenggat waktu tampaknya meningkatkan kinerja. Untuk informasi lebih lanjut tentang penjadwal dapat ditemukan dalam dokumentasi untuk kode sumber kernel Linux:
linux/Documentation/block/*osched.txt. Dan saya juga melihat peningkatan throughput baca selama operasi campuran (banyak penulisan).
"256"> / sys / block / sdc / queue / nr_requests
Jumlah permintaan I / O di buffer sebelum dikirim ke penjadwal. Beberapa pengontrol memiliki ukuran antrian internal (queue_depth) yang lebih besar daripada nr_requests dari penjadwal I / O, sehingga penjadwal I / O memiliki sedikit kesempatan untuk memprioritaskan dan menggabungkan permintaan dengan benar. Untuk penjadwal tenggat waktu dan CFQ, lebih baik jika nr_requests adalah 2 kali antrian internal pengontrol. Menggabungkan dan menyusun ulang kueri membantu perencana menjadi lebih responsif di bawah beban berat.
echo "16"> / proc / sys / vm / page-cluster
Parameter cluster halaman mengontrol jumlah halaman yang akan ditukar pada satu waktu. Dalam contoh di atas, nilai ditetapkan ke "16" agar sesuai dengan ukuran strip 64KB RAID. Ini tidak masuk akal dengan swappiness = 0, tetapi jika Anda menyetel swappiness ke 10 atau 20 maka menggunakan nilai ini akan membantu Anda ketika ukuran strip RAID 64KB.
blockdev --setra 4096 / dev / <devname >(-sdb, hdc or dev_mapper)
Pengaturan perangkat blokir default untuk banyak pengontrol RAID sering kali menghasilkan kinerja yang buruk. Menambahkan opsi di atas akan mengonfigurasi read-ahead untuk sektor 4096 * 512-byte. Setidaknya untuk operasi streaming, kecepatannya ditingkatkan dengan mengisi cache disk on-board dengan read-forward selama periode yang dibutuhkan kernel untuk menyiapkan I / O. Cache dapat berisi data yang akan diminta pada pembacaan berikutnya. Terlalu banyak membaca maju 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 pedoman lagi di tingkat sistem file. Tapi mereka belum diuji. Pastikan sistem file Anda mengetahui ukuran strip dan jumlah disk dalam larik. Misalnya, ini adalah array raid5 dengan ukuran garis 64K dari enam disk (sebenarnya lima karena satu disk digunakan untuk paritas). Rekomendasi ini didasarkan pada asumsi teoritis dan dikumpulkan 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 meningkatkan ukuran garis di atas.
PERHATIAN! Semua yang dijelaskan di atas sangat subjektif untuk beberapa jenis aplikasi. Artikel ini tidak menjamin peningkatan apapun tanpa pengujian pengguna sebelumnya dari masing-masing aplikasi. Ini hanya boleh digunakan jika perlu untuk meningkatkan daya tanggap sistem secara keseluruhan atau jika itu memecahkan masalah saat ini.
Bahan tambahan:
- dom.as/2008/02/05/linux-io-schedulers
- www.nextre.it/oracledocs/oraclemyths.html
- lkml.org/lkml/2006/11/15/40
- misterd77.blogspot.com/2007/11/3ware-hardware-raid-vs-linux-software.html
Baca lebih banyak