Memory Probleme beheben

CRIT - RAM used: 17.46 GB of 31.09 GB, Swap used: 8 GB of 8 GB, Total virtual memory used: 25.46 GB of 39.09 GB (65.1%), Committed: 66.59 GB (170.3% of RAM + Swap, warn/crit at 100.0%/150.0%) CRIT

Hallo,
wie würdet ihr ein Centos 7 rekonfigurieren um die Ursache der Meldung zu beheben?
das System hat 32 GB Ram und ist bis auf Memory komplett unauffällig. Mehr als 32 Gb können nicht gesteckt werden. 64 GB sind in der Planungsphase aber das dauert noch.
Aktuell laufen auf dem Host 130 Docker Container einer CI/CD Testing-Strecke, Tendez steigend.

Gruß
Ralf

Wie sieht es denn von innerhalb Linux gesehen aus? Also z.B. die Ausgaben von:

free -thw

und

smem -twk

(sofern smem verfügbar ist - hier eher Debian als Centos)

Gruß
Martin

sieht so aus als ob vm.swappiness relativ hoch ist?

das haben wir auch bei docker hosts. Wir haben das Rule Setting für den Committed Memory dort hoch gesetzt

Gruß! Matthias

[root@6805ca58a8b1 ~]srvfslast02# free -thw
total used free shared buffers cache available
Mem: 31G 19G 2,9G 3,1G 117M 8,9G 8,3G
Swap: 8,0G 8,0G 164K
Total: 39G 27G 2,9G
[root@6805ca58a8b1 ~]srvfslast02#

[root@6805ca58a8b1 ~]srvfslast02# smem -twk
Area Used Cache Noncache
firmware/hardware 0 0 0
kernel image 0 0 0
kernel dynamic memory 9.5G 8.6G 938.3M
userspace memory 15.6G 1.1G 14.6G
free memory 5.9G 5.9G 0

                          31.1G      15.6G      15.5G

[root@6805ca58a8b1 ~]srvfslast02#

Gruss
Ralf

Ich habe mal irgendwo gelesen, dass man bei Docker auch den swap deaktiviren kann/soll. Finde leider die Quelle auf die schnelle nicht, bei Kubernetes ist das aber z.B. eine “Vorgabe”.
Ich würde mal gucken, was genau dir den swap voll macht und falls es wirklich Docker ist, dem das swappen abgewöhnen. Aber auf jeden Fall prüfen was da den swap braucht.

Falls ich da gerade irgendwas verwechseln sollte, korrigiert mich bitte :slight_smile:

(bisschen zerhackte Darstellung, aber schon noch nachvollziehbar)

Wenn das typische Werte sind, also im Normalbetrieb auch nicht deutlich abweichen bzw. stark schwanken, dann würde ich mir um das hohe Commit keinen Kopf machen, sondern wie @mace schon schreibt die Warn/Crit Levels anpassen.

8 GB im Swap kommt mir auch arg viel vor. Das sollte schon geklärt werden, siehe z.B. Script unter http://stackoverflow.com/questions/479953/how-to-find-out-which-processes-are-swapping-in-linux#7180078

Wobei es je nach Workload schon sinnvoll sein kann, lieber den RAM für Filesystem Caches zu nutzen (was hier wohl der Fall ist) und stattdessen Prozesse bzw. deren Pages in Swap auslagern zu lassen, auf die nur selten zugegriffen wird - daher klären, was da im Detail rausgeswappt wurde.

Beste Lösung wäre natürlich noch mehr RAM :wink:

Hallo,
danke für alle Infos.
Die Docker Hosts sind aktuell Standard 08/15 Installationen. Die 8 GB Swap kommen zustande weil Oracle bei der Installation sonst zickt.
Wenn mal Zeit ist könnte man verschiedene Setups definieren aber für unsere Fälle reicht die Variante eigentlich immer aus.
Da die Container sauber laufen und sich niemand beschwert werde ich das Thema erst mal wie höheren Schwellwerten „beheben“ und mich in Ruhe damit beschäftigen.
Wir nutzen die Kombination centos 7, docker-ce und rancher 1.6 bzw 2.4.
Gruss

Aber du solltest vll. trotzdem einmal gucken was da so im swap liegt.

Genau. Die Frage war ja nicht, warum 8 GB Swap konfiguriert sind. Wenn der Oracle Installer das so will, so sei es. Aber 8 GB Swap zu 100% belegt, das kommt mir schon eher ungewöhnlich vor. Was für eine Uptime hat das System denn gerade, d.h. in welchem Zeitraum ist das aufgelaufen?

Oder auch was macht nen Oracle auf nem Docker Host :wink:

Oracle…da haben wir ja schon das Problemkind. :wink: Aber back to off-topic!

Ich weiss nicht wie ihr das macht, aber ich gebe meinen Mühlen immer SWAP = $sizeOfRam. Was sind schon 32GB, die Maschine wird vermutlich eh an nem SAN hängen und seine localdisks nur für’s OS verwenden.

Wer macht sowas heute noch? Je größer die Maschine desto kleiner der Swap trifft es doch da eher.
Meine großen Oracle oder MS-SQL Server haben nur noch ein pro Forma Swap zwischen 1-4GB. Wenn möglich wird das komplett abgeschalten.
Zu bedenken die RAM Größen sind bei den Server auch schnell mal nen halbes oder ganzes TB.

Das Problem ist das Oracle bei der Installation 8GB swap will und ich bisher einen Centos-Installer für alle Aufgaben. utze
Ja, das kann man eleganter lösen und es steht jetzt auf meiner ToDo-Liste.
Gruss
Ralf