Mailinglist Archive: opensuse-de (4628 mails)

[Adalbert Michelic <adalbert+list@xxxxxxxx>]

* On Fri, 13 Sep 2002 at 16:21 +0200, Klein, Martin Willy wrote:
> Also erst mal vielen Dank für die Antworten - ich muß allerdings gestehen,
> daß ich sie nur rudimentär verstanden habe. 
>
> (Eines meiner derzeitigen und temporären Probleme liegt darin, daß ich
> normalerweise unsere SAP-Basis betreue; dieser SAMBA-Server fliegt uns
> natürlich genau jetzt um die Ohren, wo unser Linux-Crack, der auch gerne Mal
> in den tiefen des Kernels und der Speicherverwaltung rumwühlt, in Urlaub
> ist.)

Murphy hat schon mal ein paar Worte zu diesem Thema verloren :-)

Gleich mal vorweg: Das was ich da schreibe ist zu einem Großteil nur
zusammengereimt - es ist zwar nicht so, daß ich nicht auch mal
selbst in den Kernelsourcen pfuschen würde, aber gerade in diesem
Bereich bin ich noch einigermaßen grün ...

> Vielleicht nochmal kurz zur Historie dieser Angelegenheit: 
> Als erstes hatten wir das Problem mit den "Too many open files in system."
> Daraufhin habe ich den Kernel-Parameter file-max vom Default auf 20.000
> hochgedreht. Damit lief das System wieder stabil, und auf wundersame Weise
> hatte diese Einstellung auch den höchst erfreulichen und nicht erwarteten
> Nebeneffekt, daß die CPU-Belastung (überwiegend im sys-Bereich) stark
> zurückging und das System daher deutlich besser lief.

Möglicherweise hattet ihr da viele Zugriffe auf kleine Files und der
Kernel hat sich ständig damit beschäftigt nach freien File-Handles
zu suchen.

> Allerdings stand in
> dem Hinweis aus der Support-Datenbank, nach dem ich file-max hochgedreht
> hatte, auch drin, daß damit der Bedarf an Hauptspeicher steigen würde.

Ist verständlich, die Handles müssen ja wo untergebracht werden, der
Bedarf dürfte aber nicht recht drastisch sein (gemessen an eurem
vorhandenen Speicher, da hatte ich schon wesentlich dünnere Systeme
mit mehr Handles).

> Das war der Grund, warum ich erwartete, daß nun das System anfangen würde,
> den Swap-Bereich zu nutzen, weil die tatsächlich offenen Files nun von ca.
> 12.000 auf 17.000 anstiegen - gemäß lsof-Befehl.

Sieh Dir mal den Inhalt von /proc/sys/fs/file-nr und inode-state an, da
findest Du Statistiken über den Verbrauch von File- und
Inode-Handles - Erklärung findet sich in /usr/src/linux/Doc*/sysctl/fs.txt .

> Hier mal einen Screenshot von free:
>
> taubenus:/home/klein/log # free -m
>              total       used       free     shared    buffers     cached
> Mem:          1478       1475          3          0        248        868
> -/+ buffers/cache:        358       1119
> Swap:         1999         13       1986
>
> Gemäß Eurer Erklärung wären in diesem Falle ja ca. 1,1 Giga Cache, und wenn
> jemand Hauptspeicher braucht, kriegt er die vom System in Form der
> unbelegten Seiten des Caches => Kriegt man mit trivialen Mitteln, die auch
> ein SAP-Basis-Betreuer ohne tiefere Kenntnisse der C-Programmierung und des
> Linux-Speicherverwaltung heraus, welche bzw. wie viele Seiten im Cache frei
> bzw. von welcher Anwendung belegt sind? 

Die sind alle belegt, und zwar AFAIK vom Kernel. Aber nachdem das ja
großteils Daten sind die schon auf der Platte stehen können die
Daten problemlos verworfen werden.

> So weit so gut. 
>
> Mit dem hohen sys-Anteil an der CPU-Auslastung sehe ich aber schon ein
> Problem, weil dann das System erstens schlecht läuft, und man zweitens die
> durch schlechte Parametrisierung (!?) verbratene Prozessorleistung besser
> unserer zweiten Linux-LPAR mit dem SAP-Applikationsserver zuschlagen würde.

Wer jetzt wirklich an dem sys-Anteil schuld ist, kann ich leider
nicht sagen, zumindest nicht aus der Ferne.

> Ich habe immer noch die Vermutung, daß der hohe sys-Anteil an der CPU
> einfach damit zusammenhängt, daß bei einer hohen Anzahl geöffneter Dateien
> das System wegen irgendwelcher Vorgänge im Speicher (möglicherweise im
> Cache) einfach anfängt, sich mit sich selbst zu beschäftigen. 

Tritt der hohe sys-Anteil auf, wenn das System unter Last steht,
oder auch, wenn keiner drauf zugreift? Irgendwie müssen ja auch die
Daten ins System kommen - ich weiß nicht wie das auf einer 390er
verteilt wird, möglicherweise bleibt da eh der Löwenanteil am
IO-Prozessor hängen; zumindest bei den System hier (x86) fällt bei
einem Datenzugriff immer auch ein sys-Anteil ab.

> Hättet Ihr eine Idee, was ich machen könnte, um den sys-Anteil an der CPU zu
> drücken? Vielleicht mehr Hauptspeicher => mehr freie Seiten im Cache?

Bezweifle ich, ausserdem traue ich mich zu garantieren, daß der
zusätzliche Speicher binnen Kürze belegt ist.

> Als kleiner Nachtrag hier noch ein Screenshot von free auf der anderen
> Linux-LPAR, wo unser SAP-Applikationsserver läuft:
>
> falbala:/proc/sys/vm # free -m
>              total       used       free     shared    buffers     cached
> Mem:          1973       1969          3          0          9       1673
> -/+ buffers/cache:        286       1686
> Swap:         9043       1920       7122
>
> Speziell hier würde mich die obige Frage schon gewaltig interessieren,
> wieviel vom Cache tatsächlich belegt oder freie Seiten sind.

1673 MB sind vom Cache belegt - beim Cache gibts keine freien oder
belegten Seiten - der Cache wächst und schrumpft dynamisch. Entweder
der Speicher ist ganz frei, dann ist er unter "free" zu finden, oder
er ist von was belegt - Programmen oder Cache.

> Na ja, auf jeden Fall nochmal vielen Dank für Eure Antwort und Eure Geduld.

Gern geschehen. Kleine Bitte am Rande - TOFU ist nicht gerade
angenehm zu lesen, Erklärung was und warum findet sich u.A. hier:
  http://learn.to/quote


-- 
Adalbert

PGP welcome, request public key: mailto:adalbert+key@xxxxxxxx