[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lastmittel? (gnome-system-monitor)



Gruesse!
* Christoph Schwerdtfeger <schwerdtfeger@softcontract.de> schrieb am [20.12.06 14:07]:
> Gerhard Brauer schrieb:
> > > # ps ax | grep Z
> > > 23474 ?        Z      0:00 [sh] <defunct>
> > > 23536 ?        Z      0:00 [sh] <defunct>
> > > 23573 ?        Z      0:00 [sh] <defunct>
> > 
> > Da läßt sich AFAIK lediglich rauslesen, daß es über eine shell
> > gestartete (Unter)-Prozesse sind. Syslogs nach dem Reboot durchforsten,
> > ob der Kernel gezwungen ist Prozesse zu killen (müßten Einträge wie
> > OOM-Kill oder VM-Kill sein, bin mir momentan nicht sicher).
> 
> Wird' ich mir mal anschauen, danke für den Tipp. Die Frage ist nur, wo die
> Prozesse her kommen. Können das, nicht korrekt geschlossene, SSH-Sessions
> sein?

Durchaus möglich, wenn auch die Wahrscheinlichkeit gegenüber anderen
Ursachen geringer sind. In dem *momentanen* Zustand des Systems ist
alles möglich - wichtiger ist die Frage, wie es zu so einem Zustand
kommt. Durch eine "Momentaufnahme" (wie top) läßt sich das nicht
beantworten.

vmstat bietet z.B. die Möglichkeit einer längeren Analyse und kann per
Optionen auch zeigen, welche Partitionen die IO-Last verursachen.

Wenn du selbst ran willst würde ich vorschlagen:
- Rebooten
- direkt nach dem Reboot: keine Anwendungen (Clients) v.a. für Oracle
  starten, sondern mit free die Speicherauslastung geben lassen.
  Das ist v.a. wichtig, ob Oracle (wie Torsten vermutet) aufgrund der
  Instanzen ohne nennesnwerte Datenbank-Aktivität gezwungen ist
  Swap-Speicher zu benutzen.
- vmstat laufen lassen, ps ax greppen ob und wann Zombies auftreten.
- mit tail das Syslog mitlaufen lassen

Optional wäre z.B. auch ein Analyse-Tool wie z.B. das schon
angesprochene munin eine Möglichkeit, es kann allerdings sein das munin
auch nichts mehr protokollieren kann ab einem bestimmten Zeitpunkt.

Andere Ursachen (abseits Oracle bzw. RAM) kann latürnich auch sein:
- langsame Platten bzw. Bus-System, falscher Kernel-Treiber, DMA bzw.
  Bus-Mastering seitens BIOS/PCI-Bus/Motherboard/Chipsatz.
- schlecht gewählte Partitionierung (z.B. Swap-Partition auf einer
  Slave-Platte am IDE-Bus, an dem die Master-Platte ständig genutzt
  wird).
- Debian unstable
- "falscher" Kernel, Architektur-Problem (32/64 Bit), falsches
  Scheduling für den Aufgaben-bereich.
- Was hat eigentlich Gnome auf dem Rechner zu suchen?
- Welche anderen Programme laufen da noch?

> Torsten Flammiger schrieb:
> >>Das System selber hat nur 1GB RAM und es laufen 10 Oracle Instanzen drauf,
> >                       ^^^^^^^^^^^               ^^^^^^^^^
> > wer macht denn sowas?
> > 
> > das sie bei _dem_ Speicherausbau überhaupt laufen ist schon erstaunlich.
> > Selbst wenn man jeder Instanz nur 256MB RAM zugesteht... naja, kann sich
> > jeder selber ausrechnen.
> > 
> > Torsten
> 
> Ja, als unser Chef mit dem System ankam haben wir alle recht komisch
> geguckt, aber was will man machen, es "läuft ja irgendwie"...

Es muß euch klar sein: ihr bewegt euch am Rande des Daten*verlustes*
bzw. der Daten*verfälschung*, wenn der Server in diesen Zustand
verfällt. Z.B. irgendwelche Transaktions-Geschichten.

Ihr fahrt von Hamburg nach München auf der Autobahn (linke Spur,
Vollgas) im zweiten Gang. Selbst der beste Motor hält das nicht lange
aus (Sato!).

So, daß war's jetzt aber auch von mir ;-)

Gruß
	Gerhard
-- 
Ich bin nicht die Signatur,
ich putz' hier nur!



Reply to: