Terjemahan artikel disiapake ing wayah wengi wiwitan kursus .
Secara berkala, ana pitakon babagan rekomendasi Gluster babagan tuning kernel lan apa perlu.
Kabutuhan kuwi arang banget. Ing umume beban kerja, kernel nindakake kanthi apik. Sanajan ana kekurangane. Secara historis, kernel Linux wis gelem nggunakake akeh memori yen diwenehi kesempatan, kalebu kanggo caching minangka cara utama kanggo nambah kinerja.
Umume kasus, iki bisa digunakake kanthi becik, nanging ing beban sing abot bisa nyebabake masalah.
Kita duwe akeh pengalaman karo sistem intensif memori kayata CAD, EDA lan liya-liyane, sing wiwit alon-alon ing beban abot. Lan kadhangkala kita nemoni masalah ing Gluster. Sawise kanthi ati-ati ngawasi panggunaan memori lan latensi disk sajrone pirang-pirang dina, kita entuk kakehan, iowait gedhe, kesalahan kernel (kernel oops), beku, lsp.
Artikel iki minangka asil saka akeh eksperimen tuning sing ditindakake ing macem-macem kahanan. Thanks kanggo paramèter kasebut, ora mung respon sakabèhé wis apik, nanging kluster uga stabil kanthi signifikan.
Nalika nerangake memori tuning, ing bab pisanan dipikir ing subsistem memori virtual (VM, memori virtual), kang wis nomer akeh opsi sing bisa galau sampeyan.
vm.swappiness
Parameter vm.swappiness nemtokake carane akeh kernel nggunakake swap (swap, paging) dibandhingake karo RAM. Iki uga ditetepake ing kode sumber minangka "kecenderungan nyolong memori sing dipetakan". Swappiness dhuwur tegese kernel bakal luwih cenderung kanggo ngganti kaca sing dipetakan. Nilai swappiness kurang tegese ngelawan: kernel bakal kurang saka memori. Ing tembung liyane, sing luwih dhuwur nilai vm.swappiness, luwih akeh sistem bakal nggunakake swap.
Panggunaan swapping gedhe ora dikarepake, amarga pamblokiran data sing akeh dimuat lan dibongkar menyang RAM. Akeh wong sing mbantah manawa nilai swapiness kudu gedhe, nanging ing pengalamanku, nyetel "0" ndadékaké kinerja sing luwih apik.
Sampeyan bisa maca liyane kene -
Nanging, maneh, setelan kasebut kudu ditrapake kanthi ati-ati lan mung sawise nyoba aplikasi tartamtu. Kanggo aplikasi streaming sing akeh dimuat, parameter iki kudu disetel dadi "0". Yen diowahi dadi "0", responsif sistem saya mundhak.
vm.vfs_cache_pressure
Setelan iki ngontrol memori sing digunakake kernel kanggo caching direktori lan obyek inode (dentry lan inode).
Kanthi nilai standar 100, kernel bakal nyoba mbebasake cache dentry lan inode kanthi basis "adil" menyang pagecache lan swapcache. Ngurangi vfs_cache_pressure nyebabake kernel tetep dentry lan cache inode. Nalika nilai "0", kernel ora bakal siram cache dentry lan inode amarga meksa memori, lan iki bisa gampang mimpin kanggo kesalahan metu saka memori. Tambah vfs_cache_pressure ing ndhuwur 100 nyebabake kernel dadi prioritas dentry lan flushing inode.
Nalika nggunakake GlusterFS, akeh pangguna kanthi jumlah data sing akeh lan akeh file cilik bisa kanthi gampang nggunakake jumlah RAM sing signifikan ing server amarga caching inode/dentry, sing bisa nyebabake degradasi kinerja amarga kernel kudu ngolah struktur data ing sistem. kanthi memori 40 GB. Nyetel nilai iki ing ndhuwur 100 wis mbantu akeh pangguna entuk cache sing luwih adil lan responsif kernel sing luwih apik.
vm.dirty_background_ratio lan vm.dirty_ratio
Parameter pisanan (vm.dirty_background_ratio) nemtokake persentase memori karo kaca reged, sawise tekan kang perlu kanggo miwiti flushing kaca reged ing latar mburi kanggo disk. Nganti persentase iki tekan, ora ana kaca sing disiram menyang disk. Lan nalika reset diwiwiti, mlaku ing latar mburi tanpa interrupting proses mlaku.
Parameter kapindho (vm.dirty_ratio) nemtokake persentase memori sing bisa dikuwasani dening kaca sing reged sadurunge lampu kilat dipeksa diwiwiti. Sawise ambang iki tekan, kabeh proses dadi sinkron (diblokir) lan ora diijini terus nganti I / O sing dijaluk bener rampung lan data ana ing disk. Kanthi I / O abot iki nyebabake masalah amarga ora ana cache data lan kabeh pangolahan nindakake I / O diblokir nunggu I / O. Iki ndadékaké akeh pangolahan digantung, beban dhuwur, ketidakstabilan sistem lan kinerja sing ora apik.
Mudhunake setelan kasebut nyebabake data disiram menyang disk luwih kerep lan ora disimpen ing RAM. Iki bisa bantuan sistem memori-abot oke karo siram 45-90 GB kaca caches menyang disk, asil ing latensi ageng kanggo aplikasi ngarep-mburi, ngurangi respon sakabèhé lan interaktivitas.
"1" > /proc/sys/vm/pagecache
Cache kaca minangka cache sing nyimpen data file lan program sing bisa dieksekusi, yaiku, iki minangka kaca kanthi isi file utawa piranti sing mblokir. Cache iki digunakake kanggo nyuda jumlah disk sing diwaca. Nilai "1" tegese 1% RAM digunakake kanggo cache lan bakal luwih akeh maca saka disk tinimbang saka RAM. Sampeyan ora perlu kanggo ngganti setelan iki, nanging yen sampeyan paranoid ngontrol cache kaca, sampeyan bisa nggunakake.
"deadline" > /sys/block/sdc/queue/scheduler
Penjadwal I/O minangka komponen kernel Linux sing nangani antrian maca lan nulis. Ing teori, luwih becik nggunakake "noop" kanggo pengontrol RAID sing cerdas, amarga Linux ora ngerti apa-apa babagan geometri fisik disk, mula luwih efisien supaya pengontrol, sing ngerti geometri disk, ngolah panjaluk kasebut kanthi cepet. bisa. Nanging katon kaya "deadline" nambah kinerja. Sampeyan bisa maca liyane babagan panjadwal ing dokumentasi kode sumber kernel Linux: linux/Documentation/block/*osched.txt. Lan uga aku wis ndeleng Tambah ing diwaca throughput sak operasi campuran (akeh operasi nulis).
"256" > /sys/block/sdc/queue/nr_requests
Jumlah panjalukan I/O ing buffer sadurunge dikirim menyang panjadwal. Ukuran antrian internal sawetara pengontrol (queue_depth) luwih gedhe tinimbang nr_requests panjadwal I/O, dadi panjadwal I/O duwe kasempatan cilik kanggo nggawe prioritas lan nggabungake panjalukan kanthi bener. Kanggo deadline lan CFQ schedulers, iku luwih apik nalika nr_requests 2 kaping antrian internal controller. Panjaluk gabung lan nyusun ulang mbantu panjadwal dadi luwih responsif ing beban sing abot.
echo "16" > /proc/sys/vm/page-cluster
Parameter page-cluster ngontrol jumlah kaca sing ditulis menyang swap sekaligus. Ing conto ing ndhuwur, nilai disetel dadi "16" miturut ukuran belang RAID 64 KB. Iku ora nggawe pangertèn karo swappiness = 0, nanging yen sampeyan nyetel swappiness kanggo 10 utawa 20 banjur nggunakake nilai iki bakal mbantu nalika RAID ukuran belang 64K.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc utawa dev_mapper)
Setelan piranti pamblokiran standar kanggo akeh pengontrol RAID asring nyebabake kinerja elek. Nambahake pilihan ing ndhuwur nyetel maca-ahead kanggo sektor 4096 * 512-bait. Paling ora, kanggo operasi streaming, kacepetan tambah kanthi ngisi cache disk on-chip kanthi maca-ahead sajrone wektu sing digunakake kernel kanggo nyiapake I/O. Cache bisa ngemot data sing bakal dijaluk nalika maca sabanjure. Kakehan prefetch bisa mateni I / O acak kanggo file gedhe yen nggunakake wektu disk sing bisa migunani utawa ngemot data ing njaba cache.
Ing ngisor iki ana sawetara rekomendasi liyane ing tingkat sistem file. Nanging durung dites. Priksa manawa sistem file sampeyan ngerti ukuran garis lan jumlah disk ing array. Contone, sing iki 5K belang raid64 Uploaded enem disk (bener limang, amarga siji disk digunakake kanggo paritas). Rekomendasi kasebut adhedhasar asumsi teoretis lan disusun saka macem-macem blog / artikel dening 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))Kanggo file gedhe, tambahake ukuran belang ing ndhuwur.
PENTING! Kabeh sing diterangake ing ndhuwur iku subyektif banget kanggo sawetara jinis aplikasi. Artikel iki ora njamin perbaikan apa wae tanpa uji coba pangguna sadurunge aplikasi sing gegandhengan. Sampeyan mung kudu digunakake yen perlu kanggo nambah respon sakabèhé saka sistem, utawa yen solves masalah saiki.
Bahan tambahan:
Waca liyane
Source: www.habr.com