Ikastaroa hasi bezperan prestatu zen artikuluaren itzulpena .
Aldian behin, han-hemenka, galderak sortzen dira Gluster-ek nukleoaren sintonizazioari buruzko gomendioei buruz eta horren beharra dagoen ala ez.
Gutxitan sortzen da halako beharra. Lan-karga gehienetan, kernelak oso ondo funtzionatzen du. Alde txarra dagoen arren. Historikoki, Linux kernelak memoria asko kontsumitzeko prest egon da aukera emanez gero, errendimendua hobetzeko bide nagusi gisa cachean gordetzeko barne.
Kasu gehienetan, ondo funtzionatzen du, baina karga handian arazoak sor ditzake.
Esperientzia handia dugu memoria intentsiboko sistemekin, hala nola CAD, EDA eta antzekoekin, karga astunarekin moteltzen hasi zirenak. Eta batzuetan arazoak izaten genituen Gluster-en. Egun askotan memoriaren erabilera eta diskoaren latentzia arretaz behatu ondoren, haien gainkarga, iowait izugarria, nukleoaren erroreak (kernel oops), izozketak, etab.
Artikulu hau hainbat egoeratan egindako afinazio esperimentuen emaitza da. Parametro horiei esker, erantzun orokorra hobetu ez ezik, klusterra ere nabarmen egonkortu da.
Memoriaren sintonizazioari dagokionez, lehenik eta behin begiratu beharreko gauza memoria birtualaren azpisistema (VM, memoria birtuala) da, nahasteko aukera ugari dituena.
vm.trukea
Parametroa vm.swappiness kernelak trukea (trukea, orrialdea) zenbat erabiltzen duen zehazten du RAMarekin alderatuta. Iturburu-kodean ere "mapatutako memoria lapurtzeko joera" gisa definitzen da. Truke altu batek esan nahi du nukleoak mapatutako orriak trukatzeko joera handiagoa izango duela. Truke-balio baxuak kontrakoa esan nahi du: nukleoak orrialde gutxiago egingo du memoriatik. Beste era batera esanda, zenbat eta handiagoa izango da balioa vm.swappiness, sistemak gehiago erabiliko du swap.
Trukearen erabilera handia ez da desiragarria, datu-bloke handiak RAM-ra kargatu eta deskargatzen baitira. Jende askok argudiatzen du truke-balioa handia izan behar dela, baina nire esperientziaren arabera, "0"-n ezartzeak errendimendu hobea dakar.
Hemen irakur dezakezu gehiago -
Baina, berriro ere, ezarpen hauek kontu handiz aplikatu behar dira eta aplikazio jakin bat probatu ondoren soilik. Oso kargatutako streaming aplikazioetarako, parametro hau "0" izan behar da. "0"-ra aldatzen denean, sistemaren erantzuna hobetzen da.
vm.vfs_cache_pressure
Ezarpen honek nukleoak kontsumitzen duen memoria kontrolatzen du direktorio eta inodo objektuak (dentry eta inode) cachean gordetzeko.
100 balio lehenetsiarekin, nukleoa dentry eta inode cacheak "bidezko" moduan askatzen saiatuko da pagecache eta swapcache-ra. vfs_cache_pressure gutxitzeak nukleoak dentry eta inode cacheak mantentzea eragiten du. Balioa "0" denean, nukleoak ez ditu inoiz dentry eta inodoen cachea hustuko memoriaren presioa dela eta, eta horrek erraz ekar dezake memoriarik gabeko errore bat. vfs_cache_pressure 100etik gora handitzeak nukleoak dentry eta inodoen garbiketa lehenesten ditu.
GlusterFS erabiltzean, datu-kopuru handiak eta fitxategi txiki asko dituzten erabiltzaile askok zerbitzarian RAM kopuru handia erabil dezakete inodo/dentry caching-aren ondorioz, eta horrek errendimendua hondatzea ekar dezake nukleoak datu-egiturak sistema batean prozesatu behar dituelako. 40 GB memoriarekin. Balio hau 100etik gora ezartzeak erabiltzaile askok cache bidezko gordetzea eta nukleoaren erantzuna hobetzea lortu du.
vm.dirty_background_ratio eta vm.dirty_ratio
Lehenengo parametroa (vm.dirty_background_ratio) orrialde zikinak dituen memoria-portzentajea zehazten du, eta horretara iritsi ondoren beharrezkoa da atzeko planoko orri zikinak diskora garbitzen hasteko. Ehuneko horretara iritsi arte, ez da orririk diskora garbitzen. Eta berrezartzea hasten denean, atzeko planoan exekutatzen da exekutatzen diren prozesuak eten gabe.
Bigarren parametroa (vm.dirty_ratio) behartutako flasha hasi aurretik orri zikinek okupatu dezaketen memoriaren ehunekoa definitzen du. Atalase horretara iritsitakoan, prozesu guztiak sinkronizatu egiten dira (blokeatu egiten dira) eta ezin dute jarraitu eskatutako I/O-a benetan osatu eta datuak diskoan egon arte. I/O astunekin, honek arazo bat sortzen du datuen cachean ez dagoelako eta I/O egiten duten prozesu guztiak blokeatuta daudelako I/Oren zain. Horrek zintzilik dauden prozesu ugari, karga handia, sistemaren ezegonkortasuna eta errendimendu eskasa dakar.
Ezarpen hauek gutxituz gero, datuak diskora maizago garbituko dira eta ez dira RAMan gordetzen. Honek memoria astuneko sistemei lagun diezaieke normala den 45-90 GB orrialdeko cacheak diskora garbitzea, eta, ondorioz, frontend-aplikazioen latentzia handia sortzen da, eta, oro har, erantzuna eta interaktibitatea murriztuz.
"1" > /proc/sys/vm/pagecache
Orrialde-cachea fitxategien eta programa exekutagarrien datuak gordetzen dituen cachea da, hau da, fitxategien edo blokeatutako gailuen benetako edukia duten orrialdeak dira. Cache hau diskoen irakurketa kopurua murrizteko erabiltzen da. "1" balio batek esan nahi du RAMaren % 1 erabiltzen dela cacherako eta diskotik RAMetik baino irakurketa gehiago egongo direla. Ez da beharrezkoa ezarpen hau aldatzea, baina orriaren cachea kontrolatzeko paranoia bazara, erabil dezakezu.
"epea" > /sys/block/sdc/queue/scheduler
I/O programatzailea irakurketa eta idazketa ilarak kudeatzen dituen Linux nukleoaren osagaia da. Teorian, hobe da "noop" erabiltzea RAID kontroladore adimendun baterako, Linux-ek ez baitaki ezer diskoaren geometria fisikoari buruz, beraz, eraginkorragoa da diskoaren geometria ondo ezagutzen duen kontrolagailuak eskaera bezain azkar prozesatzea. posible. Baina badirudi "epeak" errendimendua hobetzen duela. Antolatzaileei buruzko informazio gehiago irakur dezakezu Linux nukleoaren iturburu-kodearen dokumentazioan: linux/Documentation/block/*osched.txt. Eta, gainera, irakurketa-ekarpenaren igoera ikusi dut eragiketa mistoetan (idazketa asko).
"256" > /sys/block/sdc/queue/nr_requests
Bufferrean dauden I/O eskaera kopurua, programatzailera pasatu aurretik. Zenbait kontrolatzaileren barne-ilararen tamaina (ilararen sakonera) I/O programatzailearen nr_requests baino handiagoa da, beraz, I/O programatzaileak aukera gutxi ditu eskaerak behar bezala lehenesteko eta batzeko. Epea eta CFQ programatzaileetarako, hobe da nr_requests kontrolagailuaren barne-ilararen bi aldiz handiagoa denean. Eskaerak bateratzeak eta berrantolatzeak karga astunetan erantzun handiagoa izaten laguntzen dio programatzaileari.
echo "16" > /proc/sys/vm/page-cluster
Orri-kluster parametroak aldi berean trukean idazten diren orrialde kopurua kontrolatzen du. Goiko adibidean, balioa "16"-n ezartzen da, 64 KB-ko RAID bandaren tamainaren arabera. Ez du zentzurik swappiness = 0, baina swappiness 10 edo 20 gisa ezartzen baduzu, balio hau erabiltzeak lagunduko dizu RAID stripe tamaina 64K denean.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc edo dev_mapper)
RAID kontrolagailu askoren bloke-gailuen ezarpen lehenetsiek errendimendu izugarria eragiten dute askotan. Goiko aukera gehitzeak irakurketa aurreratua ezartzen du 4096 * 512 byteko sektoreetarako. Gutxienez, streaming-eragiketetarako, abiadura handitzen da txip-eko diskoaren cachea irakurketa-aurretik betez nukleoak I/O prestatzeko erabiltzen duen aldian. Cacheak hurrengo irakurketan eskatuko diren datuak izan ditzake. Aurre-bilketa gehiegik ausazko I/O hil ditzake fitxategi handietarako, baliagarria izan daitekeen diskoko denbora erabiltzen badu edo datuak cachetik kanpo kargatzen baditu.
Jarraian, fitxategi-sistemaren mailan gomendio batzuk daude. Baina oraindik ez dira probatu. Ziurtatu zure fitxategi-sistemak marra-tamaina eta array-ko disko-kopurua ezagutzen dituela. Adibidez, sei diskoko 5K stripe raid64 array bat dela (egia esan, bost, disko bat parekidetasunerako erabiltzen delako). Gomendio hauek hipotesi teorikoetan oinarritzen dira eta RAID adituek hainbat blog/artikulutatik bilduta.
-> 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))Fitxategi handietarako, kontuan hartu goian zerrendatutako marra-tamainak handitzea.
OHARRA! Goian deskribatutako guztia oso subjektiboa da aplikazio mota batzuetarako. Artikulu honek ez du inolako hobekuntzarik bermatzen erabiltzaileek erlazionatutako aplikazioen aldez aurretik probatu gabe. Sistemaren erantzun orokorra hobetzeko beharrezkoa bada edo egungo arazoak konpontzen baditu soilik erabili behar da.
Material osagarriak:
Irakurri gehiago
Iturria: www.habr.com