La traduko de la artikolo estis preparita sojle de la komenco de la kurso .
Periode, ĉi tie kaj tie, aperas demandoj pri la rekomendoj de Gluster pri kerno-agordado kaj ĉu necesas ĉi tio.
Tia bezono malofte aperas. Ĉe plej multaj laborŝarĝoj, la kerno funkcias tre bone. Kvankam estas malavantaĝo. Historie, la Linukso-kerno volis konsumi multe da memoro se ĝi ricevis la ŝancon, inkluzive por kaŝmemoro kiel la ĉefa maniero plibonigi rendimenton.
Plejofte, ĉi tio funkcias bone, sed sub peza ŝarĝo ĝi povas konduki al problemoj.
Ni havas multan sperton pri memorintensaj sistemoj kiel CAD, EDA kaj similaj, kiuj komencis malrapidiĝi sub peza ŝarĝo. Kaj foje ni renkontis problemojn en Gluster. Post zorge observi la uzadon de la memoro kaj la latencia de la disko dum multaj tagoj, ni ricevis ilian troŝarĝon, grandegan iowait, kernerarojn (kernel oops), frostiĝojn, ktp.
Ĉi tiu artikolo estas la rezulto de multaj agordaj eksperimentoj faritaj en diversaj situacioj. Danke al ĉi tiuj parametroj, ne nur la ĝenerala respondeco pliboniĝis, sed la areto ankaŭ signife stabiliĝis.
Kiam temas pri memoragordado, la unua afero por rigardi estas la virtuala memorsubsistemo (VM, virtuala memoro), kiu havas grandan nombron da opcioj, kiuj povas konfuzi vin.
vm.swappiness
Parametro vm.swappiness determinas kiom multe la kerno uzas interŝanĝon (interŝanĝon, paĝigon) kompare kun RAM. Ĝi ankaŭ estas difinita en la fontkodo kiel "tendenco ŝteli mapitan memoron". Alta interŝanĝado signifas, ke la kerno pli emas interŝanĝi mapitajn paĝojn. Malalta interŝanĝvaloro signifas la malon: la kerno paĝiĝos malpli el memoro. Alivorte, des pli alta la valoro vm.swappiness, des pli la sistemo uzos interŝanĝon.
Granda uzo de interŝanĝado estas nedezirinda, ĉar grandegaj blokoj de datumoj estas ŝarĝitaj kaj malŝarĝitaj en RAM. Multaj homoj argumentas, ke la interŝanĝvaloro devus esti granda, sed laŭ mia sperto, agordi ĝin al "0" kondukas al pli bona rendimento.
Vi povas legi pli ĉi tie -
Sed, denove, ĉi tiuj agordoj devas esti aplikataj zorge kaj nur post testado de aparta aplikaĵo. Por tre ŝarĝitaj streaming-aplikoj, ĉi tiu parametro devas esti agordita al "0". Se ŝanĝite al "0", la respondeco de la sistemo pliboniĝas.
vm.vfs_cache_pressure
Ĉi tiu agordo kontrolas la memoron konsumitan de la kerno por kaŝmemoro de dosierujoj kaj inodaj objektoj (dentry kaj inode).
Kun defaŭlta valoro de 100, la kerno provos liberigi la dentajn kaj inodajn kaŝmemorojn sur "justa" bazo al pagecache kaj swapcache. Malkreskanta vfs_cache_pressure igas la kernon konservi dentajn kaj inodajn kaŝmemorojn. Kiam la valoro estas "0", la kerno neniam forĵetos la dentran kaj inodan kaŝmemoron pro memorpremo, kaj tio povas facile konduki al senmemoreraro. Pliigi vfs_cache_pressure super 100 igas la kernon prioritati denton kaj inodan flufluadon.
Kiam vi uzas GlusterFS, multaj uzantoj kun grandaj kvantoj de datumoj kaj multaj malgrandaj dosieroj povas facile uzi signifan kvanton da RAM sur la servilo pro inodo/dentry-kaŝmemoro, kiu povas konduki al rendimento-degenero ĉar la kerno devas prilabori datumstrukturojn en sistemo. kun 40 GB de memoro. Agordi ĉi tiun valoron super 100 helpis multajn uzantojn atingi pli justan kaŝmemoron kaj plibonigitan respondecon de la kerno.
vm.dirty_background_ratio kaj vm.dirty_ratio
Unua parametro (vm.dirty_background_ratio) determinas la procenton de memoro kun malpuraj paĝoj, post atingi kiun necesas komenci flui malpurajn paĝojn en la fono al disko. Ĝis tiu ĉi procento estas atingita, neniuj paĝoj estas fluitaj al disko. Kaj kiam rekomenciĝo komenciĝas, ĝi funkcias en la fono sen interrompi funkciajn procezojn.
La dua parametro (vm.dirty_ratio) difinas la procenton de memoro kiu povas esti okupita de malpuraj paĝoj antaŭ ol deviga ekbrilo komenciĝas. Post kiam ĉi tiu sojlo estas atingita, ĉiuj procezoj iĝas sinkronaj (blokitaj) kaj ne rajtas daŭri ĝis la I/O kiun ili petis estas fakte kompletigita kaj la datenoj estas sur disko. Kun peza I/O tio kaŭzas problemon ĉar ekzistas neniu datuma kaŝmemoro kaj ĉiuj procezoj farantaj I/O estas blokitaj atendante I/O. Ĉi tio kondukas al granda nombro da penditaj procezoj, alta ŝarĝo, sistema nestabileco kaj malbona rendimento.
Malkresko de ĉi tiuj agordoj igas datumojn esti fluitaj al disko pli ofte kaj ne konservitaj en RAM. Ĉi tio povas helpi memor-pezajn sistemojn, kiuj estas en ordo kun fluado de 45-90 GB-paĝaj kaŝmemoroj al disko, rezultigante grandegan latentecon por antaŭfinaj aplikoj, reduktante ĝeneralan respondecon kaj interagadon.
"1" > /proc/sys/vm/pagecache
Paĝa kaŝmemoro estas kaŝmemoro, kiu konservas la datumojn de dosieroj kaj plenumeblaj programoj, tio estas, ĉi tiuj estas paĝoj kun la reala enhavo de dosieroj aŭ blokaj aparatoj. Ĉi tiu kaŝmemoro estas uzata por redukti la nombron da diskolegoj. Valoro de "1" signifas, ke 1% de RAM estas uzata por la kaŝmemoro kaj estos pli da legado de disko ol de RAM. Ne necesas ŝanĝi ĉi tiun agordon, sed se vi estas paranoja pri kontrolo de la paĝa kaŝmemoro, vi povas uzi ĝin.
"templimo" > /sys/block/sdc/queue/scheduler
La I/O-planilo estas Linukso-kerna komponanto, kiu pritraktas legajn kaj skribajn atendovicojn. En teorio, estas pli bone uzi "noop" por inteligenta RAID-regilo, ĉar Linukso scias nenion pri la fizika geometrio de la disko, do estas pli efike lasi la regilon, kiu bone konas la diskgeometrion, prilabori la peton tiel rapide kiel ebla. Sed ŝajnas, ke "limdato" plibonigas rendimenton. Vi povas legi pli pri planiloj en la dokumentado pri fontkodo de Linukso-kerno: linux/Documentation/block/*osched.txt. Kaj ankaŭ mi vidis pliiĝon de la legado dum miksitaj operacioj (multaj skribaĵoj).
"256" > /sys/block/sdc/queue/nr_requests
La nombro da I/O-petoj en la bufro antaŭ ol ili estas transdonitaj al la planilo. La interna vostograndeco de kelkaj regiloj (queue_depth) estas pli granda ol la nr_requests de la I/O-planisto, do la I/O-planilo havas malmulte da ŝanco konvene prioritatigi kaj kunfandi petojn. Por templimoj kaj CFQ-planistoj, estas pli bone kiam nr_requests estas 2-oble la interna atendovico de la regilo. Kunfandi kaj reordigi petojn helpas la planilon esti pli respondema sub peza ŝarĝo.
echo "16" > /proc/sys/vm/page-cluster
La paĝ-grupo kontrolas la nombron da paĝoj kiuj estas skribitaj al la interŝanĝo samtempe. En la supra ekzemplo, la valoro estas agordita al "16" laŭ la RAID-striograndeco de 64 KB. Ĝi ne havas sencon kun interŝanĝeco = 0, sed se vi agordas interŝanĝecon al 10 aŭ 20, tiam uzi ĉi tiun valoron helpos vin kiam la RAID-striograndeco estas 64K.
blockdev --setra 4096 /dev/<devnomo> (-sdb, hdc aŭ dev_mapper)
La defaŭltaj blokaparataj agordoj por multaj RAID-regiloj ofte rezultigas teruran rendimenton. Aldonante la ĉi-supran opcion agordas antaŭlego por 4096 * 512-bajtaj sektoroj. Almenaŭ, por fluaj operacioj, rapideco estas pliigita plenigante la sur-blatan diskon-kaŝmemoron kun antaŭlego dum la periodo uzata de la kerno por prepari I/O. La kaŝmemoro povas enhavi datumojn, kiuj estos petitaj en la sekva legado. Tro multe da antaŭpreno povas mortigi hazardan I/O por grandaj dosieroj se ĝi uzas eble utilan disktempon aŭ ŝarĝas datumojn ekster la kaŝmemoro.
Malsupre estas kelkaj pliaj rekomendoj ĉe la dosiersistema nivelo. Sed ili ankoraŭ ne estis provitaj. Certigu, ke via dosiersistemo konas la grandecon de la strio kaj la nombron da diskoj en la tabelo. Ekzemple, ke tio estas 5K stria raid64 tabelo de ses diskoj (fakte kvin, ĉar unu disko estas uzata por egaleco). Ĉi tiuj rekomendoj estas bazitaj sur teoriaj supozoj kaj kompilitaj de diversaj blogoj/artikoloj de RAID-fakuloj.
-> 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))Por grandaj dosieroj, konsideru pliigi la striograndecojn listigitajn supre.
ATENTO! Ĉio priskribita supre estas tre subjektiva por iuj specoj de aplikoj. Ĉi tiu artikolo ne garantias iujn ajn plibonigojn sen antaŭa uzanta testado de rilataj aplikoj. Ĝi devus esti uzata nur se necesas plibonigi la ĝeneralan respondecon de la sistemo, aŭ se ĝi solvas aktualajn problemojn.
Pliaj materialoj:
Legu pli
fonto: www.habr.com