Linux og minnebruk

[Lindsay]

Innstalerte 4GB på min webserver og trodde att nå hadde jeg massevis av minne men nå har jeg bare 60-100 tilgjengelig etter en dag eller 2 att server har stått på.Apache tar jo mesteparetn av minne sammen med MySQL men må jeg til med mere minne enn det jeg har nå?

[Manuel]

Hvordan har du egentlig "målt" minnebruken?

 

Jeg kan ta utdata fra verktøyet free som eksempel:

				total	   used	   free	 shared	buffers	 cached
Mem:		  2025	   1973		 52		  0		 38	   1674
-/+ buffers/cache:		261	   1764
Swap:		 2047		  0	   2047

På dette systemet så har jeg 2GiB (fysisk) RAM. Noe blir brukt av kjernen, men det er uinteressant i denne sammenhengen. Used-feltet på øverste linje vil etter lengre tids bruk av systemet konvergere mot total mengde med fysisk minne. I dette tilfellet så er det ikke fordi prosesser har bedt kjernen om å allokkere ekstra mye minne, men "cache"-feltet avslører at mesteparten faktisk blir brukt som harddisk-mellomlager! Noe av dette er sikkert "skitne" buffere - data som enda ikke har blitt skrevet til fastlager (harddisk), men mesteparten er data som nylig har blitt lest fra harddisk og som det er mer eller mindre sannsynlig at det blir behov for igjen.

 

Merk at swap-filen på harddisken ikke blir brukt.

 

Så lenge kjernen ikke blir nødt til å "swappe" ut "pages" til harddisk, så vil free-verdien sånn mer eller mindre står på stedet vil selv om du starter nye prosesser eller laster inn store bilder i en bildefremviser etc.

 

Verktøyet vmstat gir litt mer detaljert informasjon om hva som skjer:

 

root /home #  vmstat 1 4
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff  cache   si   so	bi	bo   in   cs us sy id wa
0  0	  0  78756  39428 1682712	0	0   102	 8   50   87  8  1 90  0
0  0	  0  78748  39428 1682712	0	0	 0	 0  122 1173  4  0 95  0
0  0	  0  78748  39428 1682712	0	0	 0	 0  127 1321  5  0 95  0
0  0	  0  78748  39444 1682696	0	0	 0	80  161 1423  5  1 94  0

Kommandoen er satt til å samle inn data i løpet av 1 sekund og gjøre 4 iterasjoner.

 

I denne sammenhengen er feltene b, si, so, bi, bo, in og cs. I samme rekkefølge:

• b Antall prosesser som er blokkerte. Dette skyldes så og si alltid fordi de venter på I/O - typisk lagringsenheter. Det ser bra ut på dette systemet, og antallet burde ikke være særlig høyt uansett.
  
• si -- "swap in"Viser mengde som kjernen har hentet inn fra swapspace. I dette tilfellet så har det ikke vært nødvendig, siden swapspace - som free-kommandoen viste - ikke blir brukt. Hvis dette skulle være flere hundre, så ville det vært ille og en minneoppgradering ville vært gunstig.
  
• so -- "swap out" Det motsatte av det ovenfor. Et høyt antall betyr altså at kjernen er nødt til å "swappe" mye for å kompensere for mangel på fysisk minne.
  
• bi -- bytes in Viser diskaksess. Er som regel ikke høyt hvis kjernen a) ikke swapper som en gal b) Nye prosesser ikke "spawnes" d) Kjørende prosesser har et stort behov for å hente data fra harddisk (stor database).
  
• bo -- bytes out Som ovenfor.
  
• in Antall "interrupts". Dette er bare indirekte relatert til mangel på RAM, og er også avhengig av hvilken frekvens "Kernel timer" er satt til.
  
• cs Antall kontekstbytter per sekund. Dette vil antakelig være mye, mye lavere på et system som ikke kjører et grafisk grensesnitt. Hva som er høyt og lavt, er avhengig av systemet, men generelt så vil "interrupts" alltid føre til kontekstbytter, ræva nettverkskontrollere plager livet av CPU med mange interrupts, ræva diskkontrollere (ikke-DMA) likeså og prosesser som ikke er IO-bundet.
   
  Mange kontekstbytter er ikke nødvendigvis en uting, men på et serversystem eller et HPC-system så vil mange kontekstbytter være lik bortkastet prosessortid.
  

Til slutt kan du jo se prosentandelen av minne de ulike prosessene bruker og mye annet snask med kommandoen ps aux:

root /home #  ps aux			   
USER	   PID %CPU %MEM	VSZ   RSS TTY	  STAT START   TIME COMMAND
root		 1  0.0  0.0   1612   548 ?		Ss   16:27   0:00 init [3]													   
root		 2  0.0  0.0	  0	 0 ?		S<   16:27   0:00 [kthreadd]
root		 3  0.0  0.0	  0	 0 ?		S<   16:27   0:00 [migration/0]
root		 4  0.0  0.0	  0	 0 ?		S<   16:27   0:00 [ksoftirqd/0]
root		 5  0.0  0.0	  0	 0 ?		S<   16:27   0:00 [watchdog/0]
root		 6  0.0  0.0	  0	 0 ?		S<   16:27   0:00 [migration/1]
root		 7  0.0  0.0	  0	 0 ?		S<   16:27   0:00 [ksoftirqd/1]
root		 8  0.0  0.0	  0	 0 ?		S<   16:27   0:00 [watchdog/1]
(...)

Prosesser hvis kommando er rammet inn i klammeparentes tilhører kjernen og kan ignoreres.

 

Oppsummering:

Hvis du har en mistanke om at MySQL eller Apache lekker minne, så kan du starte dem på nytt. Ellers: med mindre dmesg avslører linjer som "allocation failed", "process killed", "out of memory" eller noe i den retning så har du i alle fall nok fysisk+swap-minne.

 

Endret 13. januar 2008 av Manuel

[Lindsay]

OK da ble jeg litt mere beroliget