Som anges i inledningen, när "hygienreglerna" har tillämpats på systemet, har vi två möjligheter att ytterligare förbättra dess prestanda: minneskonfiguration och CPU-I/O-partitionering. Även om båda analyserna kan göras parallellt, är det mycket bekvämt att göra dem sekventiellt för att separat kvantifiera effekten och förenkla observationer. Det rekommenderas också starkt att börja med minneskonfiguration, eftersom lösningarna för detta koncept är enklare och billigare än för CPU-I/O-partitionering.
3.1. System utan brist på minne
Vissa system har aldrig någon minnesbrist alls. Ett enkelt sätt att fastställa denna situation är genom att observera om de har använt bytet. Som kan ses i exemplet har bytet (i det här fallet cirka 1200 megabyte) inte använts förrän i detta ögonblick, vilket betyder att systemet ännu inte har behövt ta till det på grund av minnesbrist:
sys1$ /sbin/swapon -sFilnamn Typ Storlek som används Priority/dev/hda7 partition 1228932 0 -1
Om denna situation kvarstår i många dagar, indikerar det att systemet förmodligen har överflödigt minne, eller åtminstone överskott av swap. På dessa system kunde vi knappast förbättra prestandan när det gäller minnesförbrukning.
3.2. Regim med minnesbrist
System upplever vanligtvis minnesbrist under vissa tidsperioder när vissa tunga processer körs. Om dessa "mörka perioder" är korta, så finns det inte mycket utrymme för förbättring när det gäller glömska. Tvärtom, om anståndsperioderna förlängs kan föreställningen mångdubblas häpnadsväckande.
Sammanfattningsvis är det första steget att avgöra om vårt system har långa perioder av brist på minne (minst några minuter) eller om dessa är korta och få (några sekunder långa). För det första fallet rekommenderas en omkonfigurering, medan för den andra, en omkonfiguration skulle förbättra den övergripande prestandan mycket lite och skulle förmodligen inte vara värt ansträngningen.
3.3. Observation av bristande minne
Nedan är en del av produktionen avvmstatför ett system som från början inte har minnesbrist, men efter några sekunder har det:
$ vmstat 2---------minne- ---swap-- -----io---- --system-- ----cpu---- swpd gratis si so bi bo i cs us sy id wa 67288 478472 188 262 282 279 1037 239 8 1 81 10 67288 478472 0 0 0 0 1002 59 2 0 99 0 4 0 7 0 7 0 7 0 7 4 2 0 99 0 67288 478472 0 0 0 24 1010 103 1 0 99 0 67288 478456 0 0 0 0 1017 467 8 1 91 0 67236 102320 34 0 46 16 1023 297 11 54 35 2 346 2 724 20 4 1424 459 15 23 0 61111640 2960 1674 20072 4210 20086 1263 273 1 6 0 93129996 3208 1960 9180 3622 9180 1190 327 1 4 0 96129996 3568 3200 0 3862 0 1245 480 1 2 0 9 999 6 225 414 4 2 0 95129988 3496 3672 0 4076 68 1328 567 2 2 0 96129988 2892 3268 0 4396 2 nr 376 438 0 478 0 1060 189 2 10 70 20 76508 474388 6 0 6 2 1012 436 8 1 91 1 76508 474404 0 0 0 0 1001 54 2 0 99 0 76508 474408 0 0 0 0 1001 57 1 0 99 0 76508 47408 0 1 0 1 0 1 0 1
Om vi hoppar över den första raden (som är ackumulerade värden), kan vi se att under kolumnerna '
och'y'
så' (swap in/swap out) värden förblir initialt på noll, och sedan '
så' avskedas; efter några ögonblick
och' antar också betydande värden. Slutligen efter cirka 20 sekunder återgår båda kolumnerna till noll.
Detta är ett typiskt exempel på ett system som upplever att minnet är slut under några sekunder. Användare av detta system kommer sannolikt att uppleva långsamma svar under dessa tider.
Vad ska vi göra åt det? om detta under hela dagen är det enda ögonblicket av brist på minne, så skulle varje minneskonfiguration bara tillåta oss att vinna upp till 20 sekunder på hela dagen, vilket uppenbarligen är försumbart. Om, tvärtom, detta beteende varade i några timmar, eller om det inträffade vid många tillfällen (vilket, kumulativt, kunde lägga till upp till timmar), är omkonfigurationen tillämplig.
3.4. minnesåterställning
Om vi har bestämt oss för att konfigurera om minnet från analysen ovan, har vi i huvudsak tre alternativ:
Ändra ordningen för utförande av processerna
ändra programmen
utöka minnet
Vi kommer att beskriva varje fall separat.
3.4.1. Ändra ordningen för utförande av processerna
Detta är den första nivån av lösning på problemet med brist på minne; Det är det enklaste och det som kräver minst investering.
Som ett exempel, betrakta ett system där två processer som körs separat efter varandra tar (totalt) fem minuter att slutföra; men om de körs samtidigt tar de en timme eller mer att avsluta. Detta är fallet eftersom varje process separat inte introducerar systemet i out-of-minne-regimen eller gör det under en mycket kort tid och intensitet, medan kombinationen av båda processerna gör det fullt ut och prestandan minskar drastiskt.
Detta problem uppstår vanligtvis i system där antalet processer är mycket högt och för enkelhetens skull för operatörerna är samtidig exekvering att föredra. Lösningen är naturligtvis att identifiera de "kombinationer" som orsakar tillståndet utanför minnet och serialisera utförandet.
3.4.2. ändra programmen
Optimeringsövervägandena som diskuteras i avsnittet "hygien" är fullt tillämpliga här. Tyvärr kör många installationer program från tredje part eller är underbemannade för det här jobbet, så de kan bara tillgripa att uppgradera fysiskt minne (se nedan.)
I många fall (särskilt odokumenterade program) kan denna procedur vara dyr (i tidsprogrammeringsavgifter), osäker (eftersom programmet inte längre kan optimeras särskilt mycket när det gäller dess minnesförbrukning) och långsam (eftersom optimering kan vara komplicerat och kräver många timmars analys) för vilken expansionen av fysiskt minne också används.
3.4.3. Utöka det fysiska minnet
I det här fallet måste du bara bestämma hur mycket minne du ska lägga till. I de flesta fall väljer folk att lägga till "minnesbanker" som vanligtvis är dubbelt så många som det befintliga minnet, och köra om prestandaanalysen för att se till att det inte längre finns någon brist.
Detta iterativa tillvägagångssätt är giltigt, men i vissa fall är det tillrådligt att ha en mer exakt uppfattning (till exempel om pengarna är knappa, eller om det inte finns några "minnesbanker" tillgängliga på marknaden, eller om vår hårdvara är nästan vid gräns för dess förmåga att växa i minnet.)
Under driften av systemet är det vanligt att observera olika episoder av brist på minne av liten betydelse, men det kommer nödvändigtvis att använda vårt utbyte. Om vi går tillbaka till utgången avvmstatFrån det föregående exemplet kommer vi att förstå att innan den kritiska perioden börjar var swapperförbrukningen 67288 block (den kunde också erhållas medswapon -s.) Denna förbrukning stiger upp till 175224 block och minskar sedan gradvis. Detta innebär att den tunga processen som överskrids med 175224-67288=107936 blockerar kapaciteten hos vårt minne med hjälp av swap. Därför, om vi lägger till just denna mängd fysiskt minne (till exempel en "bank" på 128 Mb) kan den tunga processen köras helt i RAM[1].
Uppenbarligen kräver denna typ av analys mycket tålamod och resultaten kan variera från en dag till en annan beroende på den totala belastningen av systemet.