Raksta tulkojums tika sagatavots kursu sākuma priekšvakarā .
Periodiski, šur tur, rodas jautājumi par Gluster ieteikumiem attiecībā uz kodola regulēšanu un to, vai tas ir nepieciešams.
Šāda vajadzība rodas reti. Vairumā darba slodžu kodols darbojas ļoti labi. Tomēr pastāv arī trūkums. Vēsturiski kodols Linux labprātīgi patērē daudz atmiņas, ja tiek dota iespēja, tostarp kešatmiņai kā galvenajam veiktspējas uzlabošanas veidam.
Vairumā gadījumu tas darbojas labi, taču ar lielu slodzi tas var radīt problēmas.
Mums ir liela pieredze ar atmiņu ietilpīgām sistēmām, piemēram, CAD, EDA un tamlīdzīgām, kas lielas slodzes laikā sāka palēnināties. Un dažreiz mēs saskārāmies ar problēmām Glusterā. Rūpīgi novērojot atmiņas lietojumu un diska latentumu daudzu dienu garumā, mēs saņēmām to pārslodzi, milzīgo iowait, kodola kļūdas (kodola oops), sasalšanu utt.
Šis raksts ir daudzu dažādās situācijās veiktu skaņošanas eksperimentu rezultāts. Pateicoties šiem parametriem, ir uzlabojusies ne tikai kopējā atsaucība, bet arī būtiski stabilizējies klasteris.
Runājot par atmiņas regulēšanu, pirmā lieta, kas jāņem vērā, ir virtuālās atmiņas apakšsistēma (VM, virtuālā atmiņa), kurā ir liels skaits iespēju, kas var jūs mulsināt.
vm.swapiness
Parametrs vm.swappiness nosaka, cik daudz kodols izmanto mijmaiņas (swap, peidžeru), salīdzinot ar RAM. Tas ir arī definēts avota kodā kā "tendence nozagt kartēto atmiņu". Augsta mijmaiņas intensitāte nozīmē, ka kodols būs vairāk tendēts apmainīt kartētās lapas. Zema mijmaiņas vērtība nozīmē pretējo: kodols mazāk lappušu no atmiņas. Citiem vārdiem sakot, jo lielāka vērtība vm.swappiness, jo vairāk sistēma izmantos mijmaiņas.
Plaša apmaiņas izmantošana nav vēlama, jo RAM tiek ielādēti un izlādēti milzīgi datu bloki. Daudzi cilvēki apgalvo, ka mijmaiņas vērtībai jābūt lielai, taču, pēc manas pieredzes, iestatot to uz "0", tiek nodrošināta labāka veiktspēja.
Vairāk var lasīt šeit -
Bet atkal šie iestatījumi ir jāpiemēro uzmanīgi un tikai pēc konkrētas lietojumprogrammas pārbaudes. Ļoti ielādētām straumēšanas lietojumprogrammām šim parametram jābūt iestatītam uz “0”. Mainot uz "0", sistēmas reakcija uzlabojas.
vm.vfs_cache_pressure
Šis iestatījums kontrolē atmiņu, ko kodols patērē direktoriju un inode objektu (dentry un inode) kešatmiņas saglabāšanai.
Ja noklusējuma vērtība ir 100, kodols mēģinās "godīgi" atbrīvot dentry un inode kešatmiņu, izmantojot lapas kešatmiņu un mijmaiņas kešatmiņu. Samazinot vfs_cache_pressure, kodols saglabā dentry un inode kešatmiņu. Ja vērtība ir "0", kodols nekad neizskalos dentry un inode kešatmiņu atmiņas spiediena dēļ, un tas var viegli izraisīt atmiņas trūkuma kļūdu. Palielinot vfs_cache_spiedienu virs 100, kodols piešķir prioritāti dentry un inode flushing.
Lietojot GlusterFS, daudzi lietotāji ar lielu datu apjomu un daudziem maziem failiem var viegli izmantot ievērojamu daudzumu RAM serverī inode/dentry kešatmiņas dēļ, kas var izraisīt veiktspējas pasliktināšanos, jo kodolam ir jāapstrādā sistēmas datu struktūras. ar 40 GB atmiņu. Šīs vērtības iestatīšana virs 100 ir palīdzējusi daudziem lietotājiem panākt godīgāku kešatmiņu un uzlabot kodola reaģētspēju.
vm.dirty_background_ratio un vm.dirty_ratio
Pirmais parametrs (vm.dirty_background_ratio) nosaka atmiņas procentuālo daudzumu ar netīrām lapām, pēc kuras sasniegšanas jāsāk netīro lapu skalošana fonā diskā. Kamēr šis procents nav sasniegts, neviena lapa netiek izskalota diskā. Un, kad sākas atiestatīšana, tā darbojas fonā, nepārtraucot darbības procesus.
Otrais parametrs (vm.dirty_ratio) nosaka atmiņas procentuālo daudzumu, ko var aizņemt netīrās lapas, pirms tiek sākta piespiedu zibspuldze. Kad šis slieksnis ir sasniegts, visi procesi kļūst sinhroni (bloķēti) un tiem nav atļauts turpināties, kamēr nav faktiski pabeigta to pieprasītā ievade/izvade un dati atrodas diskā. Ar smagu I/O tas rada problēmas, jo nav datu kešatmiņas un visi procesi, kas veic I/O, tiek bloķēti, gaidot I/O. Tas izraisa lielu skaitu pakarinātu procesu, lielu slodzi, sistēmas nestabilitāti un sliktu veiktspēju.
Samazinot šos iestatījumus, dati tiek biežāk izskaloti diskā un netiek saglabāti RAM. Tas var palīdzēt sistēmām ar lielu atmiņu, kur parasti ir 45–90 GB lappušu kešatmiņas izskalošana diskā, tādējādi radot milzīgu latentumu priekšgala lietojumprogrammām, samazinot vispārējo atsaucību un interaktivitāti.
"1" > /proc/sys/vm/pagecache
Lapas kešatmiņa ir kešatmiņa, kurā tiek glabāti failu un izpildāmo programmu dati, tas ir, tās ir lapas ar faktisko failu saturu vai blokierīcēm. Šī kešatmiņa tiek izmantota, lai samazinātu diska nolasījumu skaitu. Vērtība "1" nozīmē, ka kešatmiņai tiek izmantots 1% RAM, un no diska tiks lasīts vairāk nekā no RAM. Šis iestatījums nav jāmaina, taču, ja jums ir paranoisks lapas kešatmiņas kontrole, varat to izmantot.
"termiņš" > /sys/block/sdc/queue/scheduler
I/O plānotājs ir kodola komponents. Linux, kas apstrādā lasīšanas un rakstīšanas rindas. Teorētiski viedam RAID kontrolierim labāk ir izmantot "noop", jo Linux Plānotājs neko nezina par diska fizisko ģeometriju, tāpēc ir efektīvāk ļaut kontrolierim, kuram ir labas zināšanas par diska ģeometriju, apstrādāt pieprasījumu pēc iespējas ātrāk. Tomēr šķiet, ka "termiņš" uzlabo veiktspēju. Plašāku informāciju par plānotājiem var atrast kodola pirmkoda dokumentācijā. Linux: linux/Documentation/block/*osched.txt. Un arī jauktu darbību laikā (daudzi raksti) esmu redzējis lasīšanas caurlaidības pieaugumu.
"256" > /sys/block/sdc/queue/nr_requests
I/O pieprasījumu skaits buferī, pirms tie tiek nodoti plānotājam. Dažu kontrolleru iekšējās rindas lielums (queue_depth) ir lielāks nekā I/O plānotāja nr_requests, tāpēc I/O plānotājam ir maz iespēju pareizi noteikt prioritātes un apvienot pieprasījumus. Termiņa un CFQ plānotājiem ir labāk, ja nr_requests ir 2 reizes lielāks par kontroliera iekšējo rindu. Pieprasījumu apvienošana un pārkārtošana palīdz plānotājam būt atsaucīgākam lielas slodzes apstākļos.
echo "16" > /proc/sys/vm/page-cluster
Lapu klastera parametrs kontrolē lappušu skaitu, kas vienlaikus tiek ierakstītas mijmaiņas programmā. Iepriekš minētajā piemērā vērtība ir iestatīta uz "16" atbilstoši RAID joslas izmēram 64 KB. Nav jēgas, ja swappiness = 0, bet, ja iestatāt mijmaiņas vērtību uz 10 vai 20, tad šīs vērtības izmantošana jums palīdzēs, ja RAID joslas izmērs ir 64K.
blockdev --setra 4096 /dev/<devname> (-sdb, hdc vai dev_mapper)
Noklusējuma bloka ierīces iestatījumi daudziem RAID kontrolleriem bieži rada briesmīgu veiktspēju. Pievienojot iepriekš minēto opciju, tiek iestatīta lasīšana uz priekšu 4096 * 512 baitu sektoriem. Vismaz straumēšanas operācijām ātrums tiek palielināts, aizpildot mikroshēmas diska kešatmiņu ar priekšlasīšanu laikā, ko kodols izmanto ievades/izvades sagatavošanai. Kešatmiņā var būt dati, kas tiks pieprasīti nākamajā lasīšanas reizē. Pārāk daudz priekšielādēšanas var iznīcināt lielu failu nejaušu ievadi/izvadi, ja tiek patērēts potenciāli noderīgs diska laiks vai tiek ielādēti dati ārpus kešatmiņas.
Tālāk ir sniegti vēl daži ieteikumi failu sistēmas līmenī. Bet tie vēl nav pārbaudīti. Pārliecinieties, vai jūsu failu sistēma zina svītras lielumu un disku skaitu masīvā. Piemēram, ka šis ir 5K svītru raid64 masīvs no sešiem diskiem (faktiski pieci, jo viens disks tiek izmantots paritātei). Šie ieteikumi ir balstīti uz teorētiskiem pieņēmumiem, un tos no dažādiem emuāriem/rakstiem apkopojuši RAID eksperti.
-> 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))Lieliem failiem apsveriet iespēju palielināt iepriekš norādīto svītru izmēru.
UZMANĪBU! Viss, kas aprakstīts iepriekš, ir ļoti subjektīvs dažiem lietojumu veidiem. Šis raksts negarantē nekādus uzlabojumus bez iepriekšējas saistīto lietojumprogrammu testēšanas. To vajadzētu izmantot tikai tad, ja ir nepieciešams uzlabot sistēmas vispārējo reaģētspēju vai tas atrisina pašreizējās problēmas.
Papildu materiāli:
Lasīt vairāk
Avots: www.habr.com
