Terjemahan artikel disiapake ing wayah wengi wiwitan kursus .
Secara berkala, ana pitakon babagan rekomendasi Gluster babagan tuning kernel lan apa perlu.
Kebutuhan iki arang banget muncul. Ing umume beban kerja, inti bisa mlaku kanthi apik. Nanging, ana kekurangane. Sacara historis, inti Linux gelem ngonsumsi akeh memori yen diwenehi kesempatan, kalebu kanggo caching minangka cara utama kanggo ningkatake 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. Sacara teoritis, kanggo kontroler RAID sing cerdas, luwih becik nggunakake "noop" amarga Linux Penjadwal ora ngerti apa-apa babagan geometri fisik disk, mula luwih efisien yen controller, sing duwe kawruh sing apik babagan geometri disk, bisa ngolah panjalukan kasebut kanthi cepet. Nanging, "tenggat wektu" kasebut koyone nambah kinerja. Informasi luwih lengkap babagan penjadwal bisa ditemokake ing dokumentasi 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
