De oersetting fan it artikel waard taret op 'e foarjûn fan it begjin fan' e kursus .
Sa no en dan komme hjir en dêr fragen oer de oanbefellings fan Gluster oangeande kearnoanpassing en oft dat nedich is.
Dizze need komt selden foar. De kearn docht tige goed ûnder de measte wurkdruk. Hoewol't der in nadeel. Histoarysk ferbrûkt de Linux-kernel maklik in soad ûnthâld as se de kâns krije, ynklusyf foar caching as primêr middel om prestaasjes te ferbetterjen.
Yn 'e measte gefallen wurket dit geweldich, mar ûnder swiere lading kin it problemen feroarsaakje.
Wy hawwe wiidweidige ûnderfining mei wurkjen mei systemen dy't konsumearje in soad ûnthâld, lykas CAD, EDA en sa, dy't begûn te fertrage ûnder hege lading. En soms troffen we problemen yn Gluster. Nei it foarsichtich kontrolearjen fan it brûkte ûnthâld en de wachttiid fan de skiif foar mear dan ien dei, krigen wy skiifoverload, enoarme iowait, kernelfouten (kernel oops), befriest, ensfh.
Dit artikel is it resultaat fan in protte parameter tuning eksperiminten útfierd yn ferskate situaasjes. Mei tank oan dizze parameters, net allinnich de reaksjefeardigens yn it algemien ferbettere, mar ek de wurking fan it kluster waard gâns stabilisearre.
As it giet om it konfigurearjen fan ûnthâld, is it earste plak om te sjen it firtuele ûnthâldsubsysteem (VM), dat in grut oantal opsjes hat dy't jo kinne betiizje.
vm.swapppiness
Parameter vm.swappiness bepaalt hoefolle de kearn swap brûkt yn ferliking mei RAM. It is ek definiearre yn 'e boarnekoade as "tendens om yn kaart brocht ûnthâld te stellen." In hege swappiness-wearde betsjut dat de kernel mear gefoelich is foar it wikseljen fan mappen siden. In lege swappiness wearde betsjut it tsjinoerstelde: de kearn sil ruilje siden út it ûnthâld minder. Mei oare wurden, hoe heger de wearde vm.swappiness, hoe mear it systeem sil brûke swap.
Wiidweidich gebrûk fan wikseljen is net winsklik, om't enoarme blokken gegevens wurde laden en útladen yn RAM. In protte minsken beweare dat de swapinesswearde heech moat wêze, mar yn myn ûnderfining, it ynstellen op "0" resultearret yn bettere prestaasjes.
Jo kinne hjir mear lêze -
Mar wer, dizze ynstellingen moatte wurde brûkt mei foarsichtigens en pas nei it testen fan de spesifike applikaasje. Foar heech laden streamingapplikaasjes moat dizze parameter op "0" ynsteld wurde. As feroare nei "0", ferbetteret de systeemresponsiviteit.
vm.vfs_cache_pressure
Dizze ynstelling kontrolearret it ûnthâld konsumearre troch de kearn foar caching triemtafel objekten en inodes (dentry en inode).
Mei de standertwearde fan 100 sil de kernel besykje de dentry- en inode-caches op in earlike manier te befrijen nei de pagecache en swapcache. It ferminderjen fan vfs_cache_pressure feroarsaket dat de kernel dentry en inode-caches behâldt. As de wearde "0" is, sil de kearn de dentry en inode-cache nea spoelen fanwegen ûnthâlddruk, en dit kin maklik liede ta in flater sûnder ûnthâld. It ferheegjen fan vfs_cache_pressure boppe 100 soarget foar de kearn om prioriteit te jaan oan dentry en inode pageouts.
By it brûken fan GlusterFS kinne in protte brûkers mei grutte hoemannichten gegevens en in protte lytse bestannen maklik in signifikante hoemannichte RAM op 'e tsjinner brûke troch inode / dentry-caching, wat kin liede ta minne prestaasjes, om't de kernel gegevensstruktueren op in systeem moat behannelje. mei 40 GB ûnthâld. It ynstellen fan dizze parameter op grutter dan 100 hat in protte brûkers holpen om earliker caching en ferbettere kearnreaksje te berikken.
vm.dirty_background_ratio en vm.dirty_ratio
Earste parameter (vm.dirty_background_ratio) bepaalt it persintaazje ûnthâld mei smoarge siden, by it berikken dêr't it nedich is om eftergrûnspoelen fan smoarge siden nei skiif te begjinnen. Oant dit persintaazje wurdt berikt, siden wurde net flushed nei skiif. En as de reset begjint, rint it op 'e eftergrûn sûnder rinnende prosessen te ûnderbrekken.
Twadde parameter (vm.dirty_ratio) bepaalt it persintaazje ûnthâld dat kin wurde beset troch smoarge siden foardat in twongen flits begjint. Sadree't dizze drompel is berikt, wurde alle prosessen syngroane (blokkearre) en binne net tastien om fierder te rinnen oant de I / O-operaasje dy't se frege hawwe, eins foltôge is en de gegevens op skiif binne. Mei hege I / O load, dit soarget foar in probleem omdat der gjin gegevens caching en alle prosessen dwaan I / O wurde blokkearre wachtsjen op I / O. Dit resultearret yn in grut oantal hong prosessen, hege lading, systeem ynstabiliteit en minne prestaasjes.
It ferminderjen fan de wearden fan dizze parameters feroarsaket dat gegevens faker nei skiif wurde spoeld en net yn RAM opslein. Dit kin ûnthâld-swiere systemen helpe wêr't it normaal is om 45-90GB-pagina-caches nei skiif te spoelen, wat resulteart yn enoarme latency foar front-end-applikaasjes, wat de totale responsiviteit en ynteraktiviteit ferminderje.
"1"> /proc/sys/vm/pagecache
Side-cache is in cache dy't gegevens opslacht fan bestannen en útfierbere programma's, dat wol sizze, dit binne siden mei de eigentlike ynhâld fan bestannen of blokapparaten. Dizze cache wurdt brûkt om it oantal diskreads te ferminderjen. In wearde fan "1" betsjut dat de cache 1% fan RAM brûkt en d'r sil mear lêzen wurde fan skiif dan fan RAM. It is net nedich om dizze ynstelling te feroarjen, mar as jo paranoïde binne oer it kontrolearjen fan de side-cache, kinne jo it brûke.
"deadline"> /sys/block/sdc/queue/scheduler
De I / O-scheduler is in komponint fan 'e Linux-kernel dy't lês- en skriuwwachtrijen behannelet. Yn teory is it better om "noop" te brûken foar in tûke RAID-controller, om't Linux neat wit oer de fysike mjitkunde fan 'e skiif, dus it is effisjinter om de controller, dy't de skiifgeometry goed ken, it fersyk ferwurkje as fluch mooglik. Mar it liket derop dat "deadline" de prestaasjes ferbettert. Mear ynformaasje oer planners is te finen yn 'e dokumintaasje foar de Linux kernel boarnekoade: linux/Documentation/block/*osched.txt. En ik observearre ek in ferheging fan lêzen trochput by mingde operaasjes (in protte skriuwingen).
"256"> /sys/block/sdc/queue/nr_requests
It oantal I / O-oanfragen yn 'e buffer foardat se nei de planner stjoerd wurde. Guon controllers 'ynterne wachtrige grutte (queue_depth) is grutter dan de I / O-skemaer's nr_requests, sadat de I / O-skemaer net folle kâns hat om oanfragen korrekt te prioritearjen en te fusearjen. Foar deadline- en CFQ-planners is it better as nr_requests 2 kear grutter is as de ynterne wachtrige fan 'e controller. It gearfoegjen en opnij oarderjen fan queries helpt de planner mear responsyf te wêzen ûnder swiere lading.
echo "16"> /proc/sys/vm/page-cluster
De side-cluster-parameter kontrolearret it oantal siden dat tagelyk skreaun wurdt nei de swap. Yn it foarbyld hjirboppe is de wearde ynsteld op "16" om oerien te kommen mei de RAID-stripgrutte fan 64 KB. Dit makket gjin sin as swappiness = 0, mar as jo swappiness ynstelle op 10 of 20, dan sil it brûken fan dizze wearde jo helpe as de RAID-stripegrutte 64 KB is.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc of dev_mapper)
De standert ynstellings foar blokapparaat foar in protte RAID-controllers resultearje faak yn skriklike prestaasjes. It tafoegjen fan de boppesteande opsje konfigurearret read-ahead foar 4096 * 512 bytesektoren. Op syn minst foar streaming operaasjes wurdt snelheid ferhege troch it ynfoljen fan de on-chip skiif cache fia read-ahead yn 'e perioade dat de kernel brûkt om tariede I / O. De cache kin gegevens befetsje dy't sille wurde oanfrege by de folgjende lêzing. Te folle lês-foarút kin willekeurige I/O deadzje foar grutte bestannen as it potensjeel nuttige skiiftiid brûkt of gegevens bûten it cache laden.
Hjirûnder binne in pear mear oanbefellings op it nivo fan bestânsysteem. Mar se binne noch net hifke. Soargje derfoar dat jo bestânsysteem de stripegrutte en it oantal skiven yn 'e array ken. Bygelyks, dat dit is in raid5 array mei in stripe grutte fan 64K fan seis skiven (eins fiif, omdat ien skiif wurdt brûkt foar parity). Dizze oanbefellings binne basearre op teoretyske oannames en sammele út ferskate blogs / artikels troch RAID-eksperts.
-> 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))Foar gruttere bestannen kinne jo beskôgje om de boppesteande stripegrutte te fergrutsjen.
ATTENSION! Alles hjirboppe beskreaun is ekstreem subjektyf foar guon soarten applikaasjes. Dit artikel garandearret gjin ferbetteringen sûnder earst de oanbelangjende applikaasjes troch de brûker te testen. It moat allinich brûkt wurde as d'r ferlet is om de algemiene systeemresponsiviteit te ferbetterjen of as it hjoeddeistige problemen oplost.
Oanfoljende materialen:
Lês mear
Boarne: www.habr.com