Hallo zusammen,

wir sollten verschiedene Systeme nicht über einen Kamm scheren, Batchsysteme, 
die meherer Jobs gleichzeitig oder nacheinander abarbeiten sind anders zu 
betrachten als z.B. Monitoringsystem, die eine Grundlast an Abfragen und 
Speichern von Daten (auch für Grafik) haben und dazu aber auch manchmal wegen 
Störungen, Alarmierung oder Nutzeranfragen zeitlich schwankende Lasten erfüllen 
müssen in angemessener Zeit. Leider musste ich auch erleben, dass Nutzer weil 
Abfragen der Historie lange dauern können,
mehrere Abfragen parallel in verschiedenen Browserfenstern aufriefen. Das war 
nicht sinnvoll.
Wichtiger sind  Antwortzeiten für die jeweilige Anwendung, da hat die CPU auch 
ihren Anteil.



Gruß

Thomas Schäfer


-----Ursprüngliche Nachricht-----
Von: checkmk-de [mailto:checkmk-de-boun...@lists.mathias-kettner.de] Im Auftrag 
von tobias.schoe...@edeka.de
Gesendet: Freitag, 19. Mai 2017 07:31
An: li...@osit.cc
Cc: Mailinglist Check_MK
Betreff: [Check_mk (deutsch)] Antwort: CPUload .. wo liegt die richtige Grenze

Hallo, 

Bei uns ist der CPULoad pro Core auf 1,2 warning und 2,0 critical eingestellt. 
Da für das Alarmieren der 15-Minuten Load ausschlaggebend ist und ein 
dauerhafter Load über 1 pro Core bereits auf Probleme hinweisen kann, hat sich 
dieser Wert bei uns als sinnvoll heraus gestellt. Den Load kann man einfach als 
Anzahl der abgearbeiteten Threads verstehen im Verhältnis zu den maximal 
verarbeitbaren Threads, um die CPU voll auszulasten. Bei der Aussage sind die 
Wait-Events nicht berücksichtigt, die bei der Load-Berechnung mit einbezogen 
werden. 

Vor langer Zeit bin ich mal über die folgende Seite gestolpert, die das Ganze 
recht gut erklärt. 

http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages 
<http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages>  


Mit freundlichen Grüßen

i.A. Tobias Schönau
SAP Basis
EDV

EDEKA Handelsgesellschaft Hessenring mbH
Industriegebiet Pfieffewiesen
34212 Melsungen

Tel.:        05661/72-486

E-Mail:        tobias.schoe...@edeka.de

_________________________________________________________________

EDEKA Handelsgesellschaft Hessenring mbH, Melsungen
Geschäftsführer: Hans-Richard Schneeweiß (Sprecher), Hans-Jürgen Steffen
Aufsichtsratsvorsitzende: Karin Lichtlein
Eingetragen im Handelsregister des Amtsgerichts Fritzlar, HRB 11100
USt-IdentNr.: DE 1130 55864 



Von:        "li...@osit.cc" <li...@osit.cc> 
An:        Mailinglist Check_MK <checkmk-de@lists.mathias-kettner.de> 
Datum:        18.05.2017 17:51 
Betreff:        [Check_mk (deutsch)] CPUload .. wo liegt die richtige Grenze 
Gesendet von:        "checkmk-de" <checkmk-de-boun...@lists.mathias-kettner.de> 

________________________________




Hallo Leute, 
  
Bei linuxsystemen wird ja die CPUload geprüft. Ich hab gesehen das die Grenze 
bei z.B. 8 Cores bei Warning auf 40 liegt und bei Critical auf 80. Jetzt hat 
man früher ja immer gesagt Cpuload sind die Anzahl der Cores + Ram und I/O. 
Muss man das jetzt in Check_MK noch genau spezifizieren, muss man sich 
herantasten infolge von "system geht jetzt fast nicht mehr, Wert anpassen" oder 
wie sieht das nun aus? 
  
Benutze hier schon die Version 1.4.0b7 
  
Vielen Dank 
lg 
Mario
-- 
  
  

________________________________


Life ist a thing of mind and matter. I don't mind and you don't matter. [Anhang 
"signature.asc" gelöscht von Tobias Schönau/HR/EHG/EDEKA/DE] 
_______________________________________________
checkmk-de mailing list
checkmk-de@lists.mathias-kettner.de
http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de 
<http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de>  

_______________________________________________
checkmk-de mailing list
checkmk-de@lists.mathias-kettner.de
http://lists.mathias-kettner.de/mailman/listinfo/checkmk-de

Antwort per Email an