* 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@lopez.at