Hallo,
zum Thema Swap:
Es ist, wie Andreas ja schon schrieb, durchaus normal das
Datenbankserver ein vergleichbar kleinen Swapbereich haben. Wer
schonmal einen Server mit viel Swap permanent aktiv am Swappen
gesehen hat, wird schnell dahinter kommen warum das so ist. Das
System ist in dem Zustand praktisch nicht mehr nutzbar. Das kan
durchaus soweit gehen, das eine Loginshell in den Swap getrieben
wird und man auf jeden Tastendruck warten muß.
Es sollte ein gewisser Rahmen an Swap vorhanden sein, nur sollte
man den bei sehr viel RAM nicht übertreiben, weil das System im
Extremfall eh nicht mehr arbeitsfähig ist. Wieso dann die
Resourcen für Swap verschwenden?
Oracle hat daher vor Jahren die Swapanforderungen geändert, so das
große Systeme nur 16GB Swap benötigen - unabhängig ob 64GB oder 1TB
RAM verbaut sind.
Das mit Commited finde ich etwas merkwürdig. Wir haben zumindest bei
Oracle auf Linux kein System wo Commited > RAM+Swap ist. Mich
würde es durchaus interessieren, wo Du das beobachtet hast.
Bitte beachten!
In Linux sind einige Memorybereiche 'non swapable'.
Eine beliebte Falle sind hier HugePages + PageTables auf
Datenbankserver.
Wenn HugePages eingerichtet wurden, man die Datenbank startet und
diese die HugePages nicht verwendet, dann wird sie den Shared-Memroy
im normalen Speicher allokieren. Da HugePages und PageTables ‘non
swapable’ sind, kann der Shared-Memory der Datenbank in den Swap
getrieben werden…
Eigentlich hat man ja freien Speicher, nur ist dieser durch
HugePages reserviert und steht folglich für normale
Memoryanforderungen nicht zu Verfügung. Wenn dann der Shared Memory
im Swap landet wird das System praktisch arbeitsunfähig. Sollte dann
der OOM (Out of Memory) killer zuschlagen, dann hat man wenigstens
wieder eine arbeitsfähige Shell. Hier helfen dann auch sehr große
Swapbereiche nicht mehr, weil nur noch wait IO im Swap zu beobachten
ist und ab einer gewissen Swapmenge kein arbeitsfähiges System zu
erwarten ist.
Transparent HugePages sind bei Oracle nicht erlaubt...
Ich spreche hier aus leidvoller Erfahrung bei Kunden in den letzten
Jahren…
Fazit:
Bei Meldungen vom Memorycheck immer genau schauen wo die Meldung her
kommt.
Insbesondere bei Datenbankservern auf Linux muß man die Schwellwerte
für Shared-Memory anpassen, da die Defaults hier nicht brauchbar
sind.
PageTable - auch non swapable! - sollte man ebenfalls immer im Auge
behalten, da sie einen erheblichen Performanceeinfluß bekommen
können, wenn dafür zu viel RAM benötigt wird. Beim Sizing werden sie
gerne übersehen und bekommen mit zunehmenden RAM-Kapazitäten in den
Servern immer mehr Bedeutung…
Gruß
Thorsten
···
Am 21.09.2018 um 21:57 schrieb Andreas
Döhler:
Zur Anmerkung muss ich sagen, dass Systeme mit so
viel RAM im Normalfall mit sehr kleinem bis gar nicht
vorhandenem Swap betrieben werden. Das ist schon normal so.
Das Problem hier ist man muss sich im klaren sein was für
eine Art von Applikation auf dem System läuft und je nachdem
die Commit Limits einstellen.
Bei Datenbanken ist es durchaus Normal, dass das Commit
sehr weit über dem verfügbaren RAM liegt. Ob dies gut oder
schlecht ist mag ich nicht zu beurteilen. Ist nur meine
Beobachtung von verschiedensten Systemen.
Also erstmal nach der Applikation dort schauen und ich
würde bei so einem System viel eher auf echte RAM Usage prüfen
und nicht so sehr auf das Commit Limit.
Gruß
Andreas
Simon Müller <Simon.Mueller@xmart.de >
schrieb am Fr., 21. Sep. 2018 um 14:06 Uhr:
Hallo Michael,
schau dir mal
die Auslagerungsdatei des Systems an. Diese beträgt
nur 244 MB. Ich halte dies für viel zu wenig für ein
System mit 128 GB Ram. Eigentlich müsste das WARN
bereits am Swap stehen. Es sei du dann du hast die
Schwellwerte für Pagefile nicht definiert oder
fehlkonfiguriert (etwa 101%), was ich aber nicht
glaube.
Viele Grüße
Simon Müller
From: checkmk-de <checkmk-de-bounces@lists.mathias-kettner.de >
on behalf of Michael Kraus kraus@mk-hosting.net
Sent: Friday, September 21, 2018 1:46:38 PM
To: checkmk-de@lists.mathias-kettner.de
Subject: [Check_mk (deutsch)] RAM WARN bei
nur 30% Auslastung
Guten Tag,
der Status des RAM Checks ist bei rund 50GB (von
möglichen 128GB) bereits bei WARN, obwohl der
Schwellenwert dafür bei 80% liegt.
Ein Auszug aus der E-Mail Benachrichtigung:
WARN
- RAM used: 48.31 GB of 125.60 GB, Swap used:
244.00 MB of 244.00 MB, Total virtual memory used:
48.54 GB of 125.84 GB (38.6%), Committed: 126.42
GB (100.5% of RAM + Swap, warn/crit at
100.0%/150.0%)WARN
Woran
liegt das?
Bis
dahin vielen Dank und mit freundlichen Grüßen,
MK-Hosting
Michael
Kraus
Deutschherrenstraße 48
53177 Bonn
Deutschland
Mail: kraus@mk-hosting.net
Web: [https://mk-hosting.net](https://mk-hosting.net)
XMART IT Consulting GmbH
Gewerbepark Hardtwald 13
D-68723 Oftersheim
Germany
XMART Norway Offices
Karenslyst
Allé 8B
N-0278 Oslo
Norway
XMART Netherlands b.v.
Einsteinstraat
67
3316 GG Dordrecht
The Netherlands
XMART America Inc.
101
Hudson Street Suite 2100
Jersey City, NJ 07302
USA
XMART Asia
1 Fullerton Road
Singapore 049213
Singapore
XMART IT Consulting
Sdn. Bhd.
A-17-3A,
No.8, Jalan Kerinchi, Bangsar
South,
59200 Kuala Lumpur, Federal
Territory of Kuala Lumpur
Malaysia
Office:
+49 6202
85 60 59 0
Mail:
Simon.Mueller@xmart.de
Mobile:
+49 151 14227541
Web:
https://www.xmart.de
Court of
Registry:
Mannheim,
HRB 422213
Managing
Director:
Thomas
Martin
P Please consider the
environment before printing this email.
The contents of
the above mentioned e-mail is not legally
binding. This e-mail contains confidential
and/or legally
protected information. Please inform us if
you have received this e-mail by mistake
and delete it
in such a case. Each unauthorized
reproduction, disclosure, alteration,
distribution
and/or
publication of this e-mail is strictly
prohibited.
checkmk-de mailing list
checkmk-de@lists.mathias-kettner.de
Verwaltung & Abmeldung unter
[http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de](http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de)
Virenfrei. www.avg.com
_______________________________________________
checkmk-de mailing list
Verwaltung & Abmeldung unter
checkmk-de@lists.mathias-kettner.dehttp://lists.mathias-kettner.de/mailman/listinfo/checkmk-de