updatedb "klaut" Speicher
Hi Leute, weiss jemand, wie ich dem Kernel noch entlocken kann wie er seinen Speicher benutzt? Hintenstehendes typescript habe ich heute morgen mal produziert. Mir ist klar, das einiges an Speicher dann fuer die Buffer verwendet wird. Aber warum ist der used-memory von 4M auf 171M gestiegen? Als runlevel habe ich den single-user Modus gestartet und noch /etc/rc.d/boot start ausgefuehrt um die Datei-Systeme zu mounten. Als Kernel-Quellen habe ich kernel-source-2.4.18.SuSE-21 verwendet, hatte aber seit mindestens 2.4.10 dieselben Probleme. Faellt jemandem noch was ein? Peter Script started on Wed Mar 27 10:10:18 2002 bash-2.05# free -t total used free shared buffers cached Mem: 385484 10488 374996 0 872 4996 -/+ buffers/cache: 4620 380864 Swap: 136544 0 136544 Total: 522028 10488 511540 bash-2.05# cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 394735616 10747904 383987712 0 892928 5115904 Swap: 139821056 0 139821056 MemTotal: 385484 kB MemFree: 374988 kB MemShared: 0 kB Buffers: 872 kB Cached: 4996 kB SwapCached: 0 kB Active: 3532 kB Inactive: 3180 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 385484 kB LowFree: 374988 kB SwapTotal: 136544 kB SwapFree: 136544 kB bash-2.05# updatedb bash-2.05# free -t total used free shared buffers cached Mem: 385484 283808 101676 0 33592 78312 -/+ buffers/cache: 171904 213580 Swap: 136544 0 136544 Total: 522028 283808 238220 bash-2.05# cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 394735616 290631680 104103936 0 34398208 80191488 Swap: 139821056 0 139821056 MemTotal: 385484 kB MemFree: 101664 kB MemShared: 0 kB Buffers: 33592 kB Cached: 78312 kB SwapCached: 0 kB Active: 101616 kB Inactive: 11140 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 385484 kB LowFree: 101664 kB SwapTotal: 136544 kB SwapFree: 136544 kB
Hi Peter, Am Mittwoch, 27. März 2002 11:13 schrieb Peter Wiersig:
weiss jemand, wie ich dem Kernel noch entlocken kann wie er seinen Speicher benutzt?
Mit "top" kriegste eine tolle Übersicht über die laufenden Programme inkl. CPU und Speichernutzung.
Hintenstehendes typescript habe ich heute morgen mal produziert. Mir ist klar, das einiges an Speicher dann fuer die Buffer verwendet wird. Aber warum ist der used-memory von 4M auf 171M gestiegen?
weil Du updatedb gestartet hast vielleicht?!
Als runlevel habe ich den single-user Modus gestartet und noch /etc/rc.d/boot start ausgefuehrt um die Datei-Systeme zu mounten.
Als Kernel-Quellen habe ich kernel-source-2.4.18.SuSE-21 verwendet, hatte aber seit mindestens 2.4.10 dieselben Probleme.
dass updatedb etwas rechen- und speicherintensiv ist, ist doch kein Problem. Das gibt sich sobald das Proggy durchgelaufen ist. [...] Gruß Philipp -- registered Linux user number 258854
On Wed, Mar 27, 2002 at 11:35:51AM +0100, Philipp Zacharias wrote:
dass updatedb etwas rechen- und speicherintensiv ist, ist doch kein Problem. Das gibt sich sobald das Proggy durchgelaufen ist.
Noe, genau das ist ja das Problem. Du hast die Ausgabe der Tools gesehen, und da der runlevel s war gibt es keine andere Konsole. Die 2. Ausgabe von free bzw. meminfo war nachdem der updatedb beendet war. Peter
Hallo, On Wed, 27 Mar 2002, Peter Wiersig wrote:
Faellt jemandem noch was ein?
Jep. Du hast was ganz einfaches uebersehen:
Script started on Wed Mar 27 10:10:18 2002 bash-2.05# free -t total used free shared buffers cached Mem: 385484 10488 374996 0 872 4996 -/+ buffers/cache: 4620 380864 ^^^^ ^^^^ bash-2.05# free -t total used free shared buffers cached Mem: 385484 283808 101676 0 33592 78312 -/+ buffers/cache: 171904 213580 ^^^^^^ ^^^^^
Dahin "verschwindet" dein Speicher. updatedb laesst u.a. ja ein find / laufen, es wird also ein grossteil der HD eingelesen und dabei wird ganz normal gecached / gebuffert. -dnh -- Ich darf das! Ich darf das! Denn Ich bin ja Merkbefreit! Trullalaa Ich darf das! [WoKo in dag°]
On Wed, Mar 27, 2002 at 11:55:28PM +0100, David Haller wrote:
On Wed, 27 Mar 2002, Peter Wiersig wrote:
Script started on Wed Mar 27 10:10:18 2002 bash-2.05# free -t total used free shared buffers cached Mem: 385484 10488 374996 0 872 4996 -/+ buffers/cache: 4620 380864 ^^^^ ^^^^ bash-2.05# free -t total used free shared buffers cached Mem: 385484 283808 101676 0 33592 78312 -/+ buffers/cache: 171904 213580 ^^^^^^ ^^^^^
Dahin "verschwindet" dein Speicher. updatedb laesst u.a. ja ein find / laufen, es wird also ein grossteil der HD eingelesen und dabei wird ganz normal gecached / gebuffert.
Nein, es ist nicht nur der Buffer: Der used memory ist bei 170M. Wenn ich mir ne Prozess-Liste mit dem Speicher der Prozesse ausgeben lasse und die zusammen rechne, komme ich niemals auf die 170M. Die Anzeige unter cached steigt ja auch schliesslich nur um 73M und ausserdem rechnet "free -t" den buffer und cache Speicher in der 2. Zeile raus. Also noch mal: Nachdem cron.daily updatedb gestartet hat, fehlen 170M an freien Speicher. Hier ist die Ausgabe meiner laufenden Sitzung: wiersig@peter:~ $ free -t total used free shared buffers cached Mem: 385484 146484 239000 0 4884 72288 -/+ buffers/cache: 69312 316172 Swap: 136544 0 136544 Total: 522028 146484 375544 (Hab heute morgen mal wieder die /var/spool/cron/lastrun/cron.daily ge"touch"ed, damit ich ohne reboot arbeiten kann.) Peter
Hallo, On Thu, 28 Mar 2002, Peter Wiersig wrote:
Nein, es ist nicht nur der Buffer: Der used memory ist bei 170M. Wenn ich mir ne Prozess-Liste mit dem Speicher der Prozesse ausgeben lasse und die zusammen rechne, komme ich niemals auf die 170M.
Hm. Mach mal ein: free -t; ( cat /proc/[0-9]*/status | grep VmSize | \ awk '{print $2, "+"}'; echo '0'; ) | xargs | bc Der Wert in der letzten Zeile muesste dem von "-/+ buffers/cache: used" in etwa entsprechen.
Also noch mal: Nachdem cron.daily updatedb gestartet hat, fehlen 170M an freien Speicher.
Hm. Mach mal obiges vor und nach dem updatedb. Und lass ein 'top' (nach Speicher sortiert -> 'M' eingeben) mitlaufen, vielleicht faellt dir ja da was 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?) Ah! Und was steht bei dir in der rc.config? grep UPDATEDB /etc/rc.config -dnh -- Christ, their _intention_ is to have the OS drop its pants, bend over, and ask the whole bloody net to remotely install any bits at all . . . and then they're surprised it turns out to be a serious security flaw? This is moronic even by the standards set by Microsoft. -- David P. Murphy
On Thu, Mar 28, 2002 at 09:09:25PM +0100, David Haller wrote:
Hallo,
On Thu, 28 Mar 2002, Peter Wiersig wrote:
Nein, es ist nicht nur der Buffer: Der used memory ist bei 170M. Wenn ich mir ne Prozess-Liste mit dem Speicher der Prozesse ausgeben lasse und die zusammen rechne, komme ich niemals auf die 170M.
Hm. Mach mal ein:
free -t; ( cat /proc/[0-9]*/status | grep VmSize | \ awk '{print $2, "+"}'; echo '0'; ) | xargs | bc
Der Wert in der letzten Zeile muesste dem von "-/+ buffers/cache: used" in etwa entsprechen.
Also noch mal: Nachdem cron.daily updatedb gestartet hat, fehlen 170M an freien Speicher.
Hm. Mach mal obiges vor und nach dem updatedb.
----- Script started on Sat Mar 30 13:40:23 2002 bash-2.05# mount /dev/hda4 on / type ext2 (rw) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) /dev/hda1 on /boot type ext2 (rw) shmfs on /dev/shm type shm (rw) bash-2.05# uname -a Linux peter 2.4.18 #2 Mon Mär 25 09:55:02 CET 2002 i686 unknown bash-2.05# ls -l /usr/src/linux total 12 drwxr-xr-x 3 root root 4096 Dec 23 17:45 kernel-modules lrwxrwxrwx 1 root root 17 Mar 21 15:24 linux -> linux-2.4.18.SuSE drwxr-xr-x 15 root root 4096 Mar 28 17:33 linux-2.4.18.SuSE drwxr-xr-x 7 root root 4096 Jul 8 2001 packages bash-2.05# lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 02) 00:04.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:04.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:09.0 SCSI storage controller: Tekram Technology Co.,Ltd. TRM-S1040 (rev 01) 00:0a.0 Multimedia video controller: 3Dfx Interactive, Inc. Voodoo 2 (rev 02) 00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) 00:0c.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) bash-2.05# cat /proc/filesystems nodev rootfs nodev bdev nodev proc nodev sockfs nodev tmpfs nodev shm nodev pipefs ext3 ext2 minix nodev nfs nodev devpts reiserfs bash-2.05# fdisk -l Disk /dev/hda: 255 heads, 63 sectors, 1245 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 1 2 16033+ 83 Linux /dev/hda2 3 394 3148740 83 Linux /dev/hda3 395 411 136552+ 82 Linux swap /dev/hda4 412 1245 6699105 83 Linux 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 bash-2.05# Script done on Sat Mar 30 14:18:37 2002 -----
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 frcode war nicht sichtbar
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.
Ah! Und was steht bei dir in der rc.config? grep UPDATEDB /etc/rc.config
RUN_UPDATEDB="yes" RUN_UPDATEDB_AS="nobody" UPDATEDB_NETPATHS="" UPDATEDB_PRUNEPATHS="/S.u.S.E. /mnt /cdrom /tmp /usr/tmp /var/tmp \ /var/spool /proc /windows /www-mirror /var/www" UPDATEDB_NETUSER="" Peter
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
On Thu, Apr 04, 2002 at 07:53:07PM +0200, David Haller wrote:
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:
[Sorry, war ueber Ostern weg]
*schnaub*, unverschaemt ;)
Hm. Das riecht schon sehr nach Speicherleck, denn die beiden letzten Zeilen (die /proc/[0-9]*/status VmSize Werte bleiben gleich...
Ja, die Frage ist eher wo es leckt.
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?
Naja beendet sich und entfernt sich aus der Liste.
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")
Hm, ich glaube schon das das auch zum Problem fuehrt. Ich setzte kuerzlich mal fsv (grafisches "du") und nachdem es beendet war stellte ich den gleichen "Speichermangel" fest.
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...
Ja, werde ich mal probieren. Peter
Hallo, On Mon, 08 Apr 2002, Peter Wiersig wrote:
On Thu, Apr 04, 2002 at 07:53:07PM +0200, David Haller wrote:
Hm. Das riecht schon sehr nach Speicherleck, denn die beiden letzten Zeilen (die /proc/[0-9]*/status VmSize Werte bleiben gleich...
Ja, die Frage ist eher wo es leckt.
Ack.
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")
Hm, ich glaube schon das das auch zum Problem fuehrt. Ich setzte kuerzlich mal fsv (grafisches "du") und nachdem es beendet war stellte ich den gleichen "Speichermangel" fest.
Hm. Das wuerde dann auf ein leck in der libc hindeuten... Oder gar im Kernel. Was sagen: $ uname -r $ /lib/libc.so.6 | head -1 $ gcc --version
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...
Ja, werde ich mal probieren.
Gut. ;) -dnh -- The correct answer is a grunt, followed by ripping the offender open. HTH. -- Shalon Wood in the SDM
participants (3)
-
David Haller
-
Peter Wiersig
-
Philipp Zacharias