Speicherverbrauch von udev unter SLES 10 SP2

[ToFe]

Hallo

Es gibt hier einen Webserver, auf dem so eine Art Java-Anwendung mit Datenbankanbindung läuft.

Diese Anwendung läuft "nicht zufriedenstellend", v.a. der Hauptspeicherverbrauch ist langsam kritisch, weil unsere ESX/VSphere 4.1 - Server nur 128 GB RAM haben.

Die Anwendungsprobleme werden von externen Dienstleistern "gelöst", die kaufen wir aber nur ein paar Stunden (Mein AG ist ne Behörde), Linux-"Probleme" (wahrscheinlich Einstellungsprobleme) fallen da wohl eher untern Tisch, z.B. /var wäre fast vollgelaufen.

Meine Frage: ist es normal, dass /udev 32GB gross ist? Ist das ein Problem?

1027 root@zzzweb:/var/log# more /etc/SuSE-release

SUSE Linux Enterprise Server 10 (x86_64)

VERSION = 10

PATCHLEVEL = 2

1028 root@zzzweb:/var/log# uname -a

Linux zzzweb 2.6.16.60-0.21-smp #1 SMP Tue May 6 12:41:02 UTC 2008 x86_64 x86_64 x86_64 GNU/Linux

1029 root@zzzweb:/var/log# df -ahl

Filesystem Size Used Avail Use% Mounted on

/dev/sda2 7.9G 4.2G 3.4G 56% /

proc 0 0 0 - /proc

sysfs 0 0 0 - /sys

debugfs 0 0 0 - /sys/kernel/debug

udev 32G 96K 32G 1% /dev

devpts 0 0 0 - /dev/pts

/dev/sda6 20G 13G 6.0G 68% /home

/dev/sda5 20G 5.4G 14G 29% /var

proc 0 0 0 - /var/lib/ntp/proc

none 0 0 0 - /proc/sys/fs/binfmt_misc

1030 root@zzzweb:/var/log

top - 10:00:25 up 42 days, 20:53, 4 users, load average: 0.40, 0.67, 1.42

Tasks: 103 total, 1 running, 102 sleeping, 0 stopped, 0 zombie

Cpu(s): 9.6%us, 0.6%sy, 0.9%ni, 88.8%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st

Mem: 66007800k total, 45773616k used, 20234184k free, 473388k buffers

Swap: 2104472k total, 31144k used, 2073328k free, 7057400k cached

Ist der Speicherverbraucht ein "Problem"? Oder ist das eher virtuell, wie /proc?

Ciao

[flashpixx]

/dev worauf sich Dein udev bezieht, sind alle Devices, da "rum zu löschen", würde ich nicht empfehlen. Die Devices werden durch den Bootvorgang belegt, z.b. /dev/sda wird die Festplatte sein. Das Dev-Devices belegt nach Deiner Angabe 1% des Speicherplatzes, Home dagegen 68%.

Generell würde ich die Performance Probleme auf den Garbage Collector schieben bzw. die Einstellungen von diesem. Aber ohne eine genauere Fehleranalyse und Systemanalyse kann man da nicht wirklich etwas daran ändern. Sprich zuerst einmal wären die Anforderungen des Dienstes zu klären und danach entsprechend die Systemkomponenten und deren Einstellungen

[ToFe]

Wie kommt es das /dev ganze 32 GB gross ist, obwohl nur 96 KB gebraucht werden? das ist deutlich über Faktor 100.000 dazwischen ....

Ist das real verbrauchter Speicher oder virtuell wie /proc? /proc hat allerdings drei Nullen als Grössenangabe(n)

[Jejerod]

# mount | grep ^udev

udev on /dev type tmpfs (rw)

/dev ist ein tmpfs, ein filesystem im RAM. Es belegt nur soviel, wie die Dateien (oder hier, nodes) darunter belegen. Ich vermute mal udevd legt die maximale Größe von /dev in relation zum verfügbaren Hauptspeicher fest.

[mariux]

hi..

/dev ist als tmpfs gemountet und hat damit ohne weitere angabe eigentlich als default groesse die hälfte des verfügbaren hauptspeichers..

(widerspricht allerdings komischerweise deiner aussage von 128 GB hauptspeicher)

da aber normalerweise kein user da was reinschreiben darf und auch nur 96K belegt sind (bei mir sind es immerhin 1.4MB) ist das voellig egal und hat mit deinem ursprungsproblem nichts zu tun.

zu klaeren ist allerdings, in wiefern der hauptspeicherverbrauch kritisch ist? java holt sich ersteinmal per default unmengen an speicher, belegt diesen allerdings nicht wirklich.. ausserdem laeuft die Garbage Collection auch nicht staendig und der von java belegte speicher ist u.U. gar nicht mehr referenziert -> wenn java neuen speicher braucht, kann es den meist selbst wieder freigeben und alles laeuft wunderbar..

problematisch wird es erst, wenn die anwendung wirklich abstuerzt.. und bei 128GB wuerd ich einfach mal behaupten, dass das problem mit mehr speicher wohl nicht geloest sein darf, sondern dass da offensichtlich von error by design ausgegangen werden kann.. d.h. die anwendung ist muell 8)

fast alle "zu wenig" speicher probleme sind hausgemacht und erfordern meist eine umprogrammierung der anwendung.. 8)

m.

[ToFe]

/dev ist als tmpfs gemountet und hat damit ohne weitere angabe eigentlich als default groesse die hälfte des verfügbaren hauptspeichers.. (widerspricht allerdings komischerweise deiner aussage von 128 GB hauptspeicher)

Danke. Das hatte ich unklar formuliert: 128 GB hat der ganze ESX-Server, auf dem laufen aber noch andere Maschinen, der Maschine ZZZWEB sind bisher 64 GB zugewiesen. Woher hast du denn die Info mit "eigentlich als default groesse die hälfte des verfügbaren hauptspeichers.."?

fast alle "zu wenig" speicher probleme sind hausgemacht und erfordern meist eine umprogrammierung der anwendung..

Sag das meinem Boss, die Antwort kannst Du noch hinter der Jupiter-Umlaufbahn hören .....

[mariux]

Woher hast du denn die Info mit "eigentlich als default groesse die hälfte des verfügbaren hauptspeichers.."?

das weiss man 8)..

aber wenn nicht stehts hier: http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt

warum man das wissen sollte: der kernel hat keine chance dort belegten speicher wieder freizugeben.. daher ist es wichtig die grösse zu beschränken, falls benutzer auf einem tmpfs schreibberechtigung haben oder sobald mehr als ein tmpfs verwendet wird... für das /dev also völlig ungefährlich.. 8)

gruss m.