![](https://seccdn.libravatar.org/avatar/7b33cb1e776e35b87edb8ef09f0c888f.jpg?s=120&d=mm&r=g)
Hallo, [Sorry, war ueber Ostern weg] On Sat, 30 Mar 2002, Peter Wiersig wrote:
On Thu, Mar 28, 2002 at 09:09:25PM +0100, David Haller wrote:
On Thu, 28 Mar 2002, Peter Wiersig wrote:
Nein, es ist nicht nur der Buffer: [diverse Angaben]
Sieht normal aus...
bash-2.05# free -t; ( cat /proc/[0-9]*/status | grep VmSize | awk '{print $2, "+""}'; echo '0';)|xargs|bc total used free shared buffers cached Mem: 385484 19252 366232 0 1024 12932 -/+ buffers/cache: 5296 380188 Swap: 136544 0 136544 Total: 522028 19252 502776 11696
bash-2.05# updatedb
bash-2.05# free -t; ( cat /proc/[0-9]*/status | grep VmSize | awk '{print $2, "+""}'; echo '0';)|xargs|bc total used free shared buffers cached Mem: 385484 270932 114552 0 31248 78852 -/+ buffers/cache: 160832 224652 Swap: 136544 0 136544 Total: 522028 270932 251096 11696
Hm. Das riecht schon sehr nach Speicherleck, denn die beiden letzten Zeilen (die /proc/[0-9]*/status VmSize Werte bleiben gleich...
Und lass ein 'top' (nach Speicher sortiert -> 'M' eingeben) mitlaufen, vielleicht faellt dir ja da was auf.
find stabil bei 844 (Size / RSS) "sort -f " steigt bis ca 20M
Und faellt dann wieder ab?
frcode war nicht sichtbar
Das "blitzt" auch immer nur recht kurz auf...
Wenn dann wirklich was fehlt, dann hast du wohl ein Speicherleck in einem der verwendeten Programme (u.a. find, sort, frcode, sed, bigram, code)... Was setzt du denn ein? (Kernel- / SuSE- / find-Version?)
Kernel 2.4.18.SuSE-21 / SuSE 7.2 / GNU find version 4.1.6
An die Programme glaub ich bei diesem Problem eher nicht. Ich vermute mal das der Kernel mich da irgendwie falsch versteht.
Wuerde mich eigentlich wundern, bes. da du nen 2.4.18er Kernel verwendest. Hast du schonmal da Update-Verzeichnis bei Suse durchgeforstet? Und, genau: teste mal, ob's das gleiche Symptom gibt, wenn du selbst ein 'find / -fstype ext2' (ggfs. erweitere/schraenke das passend (ein) wg. "PRUNE") Wenn da dann der Speicher "verschwindet"... Ansonsten: haenge ein '| sort -f' an, usw... updatedb ist ein bashscript, da kann man dann die genauen Aufrufe nachschauen...
RUN_UPDATEDB_AS="nobody" UPDATEDB_PRUNEPATHS="/S.u.S.E. /mnt /cdrom /tmp /usr/tmp /var/tmp \ /var/spool /proc /windows /www-mirror /var/www"
Ok. Hm. Halt. Ich vermisse da '/dev/shm'... Nimm am besten mal '/dev' mit in die PRUNEPATHS mit auf... Achso, bei mir raeumt updatedb sogar auf *g*: # free -t total used free shared buffers cached Mem: 319892 315116 4776 0 82472 153140 -/+ buffers/cache: 79504 240388 Swap: 393548 1620 391928 Total: 713440 316736 396704 # myupdatedb # free -t total used free shared buffers cached Mem: 319892 261204 58688 0 109172 80112 -/+ buffers/cache: 71920 247972 Swap: 393548 36048 357500 Total: 713440 297252 416188 (myupdatedb ist (fast) nur der code aus /etc/cron.daily/aaa_base der updatedb aufruft, da ich updatedb nur bei Bedarf (nach groesseren Aenderungen im FS) aufrufe). Achja: # rpm -qf /usr/bin/updatedb `which sort`; uname -r find-4.1-73 textutil-2.0-72 2.4.16-1 -dnh -- Life is full of small and large disappointments, and then you die. -- M. Andrews, in the Monastery