---

Jeg har et lille problem med en Linux 2.4 maskine. Den
bruger for meget ram til buffers. Jeg ved det er ganske
normalt, at der bruges meget RAM på buffers, men under
normale omstændigheder frigives det, når der er brug for
RAM til andre formål.

Jeg har et dagligt cron job, der kræver en stor mængde
RAM. De første 88 gange efter maskinen blev startet op
fik det alt det RAM, det havde brug for. Men nu står det
bare og trasher helt vildt på swap.

Hvad kan være årsagen til, at den ikke vil frigive de
buffers, når der er mere brug for dem til andre formål?
Her er output fra free kommandoen:

total used free shared buffers
cached
Mem: 1291668 1271616 20052 0 411432
4294593624
-/+ buffers/cache: 18014394215748544 4295025108
Swap: 2096376 1396316 700060

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
....
> Her er output fra free kommandoen:
>
> total used free shared buffers
> cached
> Mem: 1291668 1271616 20052 0 411432
> 4294593624
> -/+ buffers/cache: 18014394215748544 4295025108
> Swap: 2096376 1396316 700060
>

Hm, det ligner negative tal udskrevet som unsigned.

Hvad står der i /proc/meminfo (hvis det hedder sådan på en 2.4 kerne)?

Hvilken 2.4 kerne? 32bit eller 64bit?

Mogens
--
Mogens Kjær, Dataarkæolog
Email: mk@datamuseum.dk
Homepage: http://www.datamuseum.dk

---

Mogens Kjaer wrote:
>
> Kasper Dupont wrote:
> ...
> > Her er output fra free kommandoen:
> >
> > total used free shared buffers
> > cached
> > Mem: 1291668 1271616 20052 0 411432
> > 4294593624
> > -/+ buffers/cache: 18014394215748544 4295025108
> > Swap: 2096376 1396316 700060
> >
>
> Hm, det ligner negative tal udskrevet som unsigned.

Ja, cached er højst sandsynligt et negativt tal. Det sker en
gang i mellem, men det har aldrig givet anledning til nogen
problemer ud over, et output, der ser lidt underligt ud.

Men det er slet ikke det, der er mit problem. Problemet er
buffers. Systemet bruger ikke mere RAM på page cache end
forventet.

>
> Hvad står der i /proc/meminfo (hvis det hedder sådan på en 2.4 kerne)?

[kasperd@hactar:pts/23] cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 1322668032 1302609920 20058112 0 437211136
18446744073338343424
Swap: 2146689024 375152640 1771536384
MemTotal: 1291668 kB
MemFree: 19588 kB
MemShared: 0 kB
Buffers: 426964 kB
Cached: 4294596152 kB
SwapCached: 8636 kB
Active: 637380 kB
Inactive: 426160 kB
HighTotal: 393152 kB
HighFree: 1024 kB
LowTotal: 898516 kB
LowFree: 18564 kB
SwapTotal: 2096376 kB
SwapFree: 1730016 kB
[kasperd@hactar:pts/23]

>
> Hvilken 2.4 kerne? 32bit eller 64bit?

2.4.22-1.2199.5.legacy.nptl 32bit athlon.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
....
> Ja, cached er højst sandsynligt et negativt tal. Det sker en
> gang i mellem, men det har aldrig givet anledning til nogen
> problemer ud over, et output, der ser lidt underligt ud.

Men det kunne tyde på, at noget i kernens memory tabeller ikke
har det så godt. Måske bliver kernen selv narret af dette
"store" tal.

....
>>Hvilken 2.4 kerne? 32bit eller 64bit?
>
>
> 2.4.22-1.2199.5.legacy.nptl 32bit athlon.
>

En FC1 legacy?

Jeg havde frygtelige problemer på en RH9 maskine med
RH's kerner. Disse blev løst ved at tage den nyeste
kernel.org 2.4.x kerne, tage .config fra RH's kerne
og kompilere kernen selv. Det var måske et forsøg værd?

Mogens

--
Mogens Kjær, Dataarkæolog
Email: mk@datamuseum.dk
Homepage: http://www.datamuseum.dk

---

Mogens Kjaer wrote:
>
> Kasper Dupont wrote:
> ...
> > Ja, cached er højst sandsynligt et negativt tal. Det sker en
> > gang i mellem, men det har aldrig givet anledning til nogen
> > problemer ud over, et output, der ser lidt underligt ud.
>
> Men det kunne tyde på, at noget i kernens memory tabeller ikke
> har det så godt.

Hvis det virkeligt var tilfældet ville jeg forvente langt værre
symptomer. Jeg har mere på fornemmelsen, at det bare er en
tæller, hvor et enkelt increment eller decrement er blevet
glemt.

> Måske bliver kernen selv narret af dette "store" tal.

Tanken har slået mig. Men det er forekommet mange i løbet af de
sidste 2-3 måneder uden at det har givet problemer.

>
> ...
> >>Hvilken 2.4 kerne? 32bit eller 64bit?
> >
> >
> > 2.4.22-1.2199.5.legacy.nptl 32bit athlon.
> >
>
> En FC1 legacy?

Ja.

>
> Jeg havde frygtelige problemer på en RH9 maskine med
> RH's kerner. Disse blev løst ved at tage den nyeste
> kernel.org 2.4.x kerne, tage .config fra RH's kerne
> og kompilere kernen selv. Det var måske et forsøg værd?

Måske, men de har jo backportet en del features fra 2.6 som
f.eks. nptl. Jeg ved ikke rigtig om jeg kan forvente at alle
applikationer vil virke uden. Desuden er det lidt vanskeligt
at afgøre om problemet er løst når det tager næsten tre
måneder at reproducere symptomerne.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
>
> Hvad kan være årsagen til, at den ikke vil frigive de
> buffers, når der er mere brug for dem til andre formål?

Jeg spekulerer på, om det kan være fordi et eller andet leaker
buffer heads, så deres usage count aldrig kommer ned på nul.
Er der nogen måde at finde ud af, hvad det er, der er bufferet?
Kan jeg se hvor mange sektorer der er bufferet fra hvert block
device?

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);

---

Kasper Dupont wrote:
>
> Er der nogen måde at finde ud af, hvad det er, der er bufferet?

Jeg prøvede at lade en process stå og fylde så meget af
hukommelsen den kunne med nuller. Imens prøvede jeg så at læse
tilfældige 512 bytes sektorer fra /dev/mem. Dermed fik jeg et
fingerpeg om årsagen. Det tyder på der er en leak i et af mine
egne kernemoduler. Og det har jeg ellers brugt i over et år
uden at opdage problemet. Jeg vil grave mig ned i min kildekode,
nu ved jeg hvad jeg skal kigge efter.

--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my new email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,6,_+2,_+7,_+6);