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
Post by Andreas DöhlerZur 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
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
------------------------------------------------------------------------
*Sent:* Friday, September 21, 2018 1:46:38 PM
*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.
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
Web: 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
*Mobile:* +49 151 14227541 <tel:01511%204227541>
*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
Verwaltung & Abmeldung unter
http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virenfrei. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
checkmk-de mailing list
Verwaltung & Abmeldung unter
http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de