Performance Probleme nach Virtuaisierung

[Klaas]

Hallo, wir haben folgendes Problem.

wir haben neue Server gekauft. Darauf eine VMware installiert.
Jetzt haben wir 32 Kerne a 2,8 Gigaherz zur Verfügung.
Dazu 60 Gigabyte Arbeitsspeicher und ein SAN mit 2x8G Fiberchannel und große/schnelle Raid's für jeden Typ (System, Daten, Translog).

Auf dem Domino-Server läuft neben Mails und so eine Gedys-Intraware. Das Gedys-System bringt einen Update-Agent mit sich welcher jede Nacht die Änderungen aus der Warenwirtschaft sofern diese die Kundenakte betreffen in alle Dokument vererbt. Der Source-Code für diesen Agent ist für uns nicht einsehbar/veränderbar. Dieser Agent läuft nun jede Nacht mit 100% auf 1 Kern. Die anderen 31 Kernen arbeiten zwar die andere Agents ab, jedoch ist es im System spürbar das der Agent die Datenbank belastet.
Damit ist das ganze System langsam und der Agent ist morgens nicht fertig.
Kennt irgendjemand eine Möglichkeit wie ich dem Agent mehr Rechenleistung zukommen lassen kann?

Ich hoffe ich habe keine Info vergessen und freue mich über die Antworten.

[halle]

Moin,

wie lange läuft denn der Agent mit einem Kern auf 100%?
Was für ein Agent ist es, Java, LS oder Formel?
Wie viele Kerne habt ihr der VM zugewiesen, wie ist das Sizing der VM?
Wie viele Dokument sind denn betroffen?
Was für Systeme liegen noch auf dem Raid, eventuell liegt da noch was anderes mit viel I/O?
Was für Platten sind in dem SAN verbaut?
Wie ist die gesammte Auslastung des VMWare Hosts?
Betriebssystem des Domino Server?
60GB für 32 Kerne hört sich wenig an!

Guck mal hier: http://www-01.ibm.com/support/docview.wss?uid=swg27008849#General%20Server%20Performance%20Resour


Halle

[Ralf_M_Petter]

Ohne Source des Agents ist es natürlich schwierig. Aber eines kann man mit relativ hoher Sicherheit sagen, wenn der Agent wirklich ein Core komplett zu 100% auslastet, dann kann man Probleme im IO Bereich oder zu knappen Hauptspeicher ausschließen, da IO begrenzte Workloads eine geringe CPU Auslastung haben.

Die einzige Methode, ein wenig Einblick in die Funktionsweise des Agent zu bekommen, ist sich mit dem Prozess Explorer von Sysinternals die Stacktraces des Agent Managers anzuschauen während der Agent läuft. Dami sollte man zumindest einen Eindruck bekommen welche Notes APIs der Agent am meisten benutzt. z.B getNthDocument wäre ein heißer Kandidat für so ein Problem. Umn das Problem zu beheben, brauchst du dann aber erst wieder den Autor des Agents.

Grüße

Ralf

[Tode]

Ich muss Dir widersprechen, Ralf: in sehr vielen Fällen sind zu geringe ios für Prozessorauslastungen von 100% verantwortlich. Ich würde mit der Untersuchung / dem Monitoring von io beginnen, zu 99% liegt die Ursache dort...

z.B. kann man den falschen Controller auswählen für die Virtuellen Platten, dann geht die Performance extrem in den Keller...

[pram]

Wurden die Maschinen migriert oder neu aufgesetzt. Wurden die VMWare Tools auf gen Gastmaschinen installiert?

Gruß
Roland

[Ralf_M_Petter]

Hallo Thorsten!

hast du dafür auch eine Begründung. Warum soll der Prozessor ausgelastet sein, wenn er permanent auf das IO Subsystem wartet? Siehe z.B.

http://serverfault.com/questions/547093/windows-iowait-cpu-utilization-reporting?lq=1

Grüße

Ralf

[m3]

@Ralf:

Domino depends on the OS and hardware to perform disk I/O operations. If these operations consume excessive CPU and leave virtually no CPU cycles for Domino to perform any additional computation, the performance of the whole server will suffer and response time for users can increase to unacceptable levels.

In the same way as we see an important decrease of CPU when performing a file copy directly on the hardware vs under VMware ESX, we also verified that the same mail workload performed for Domino showed lower CPU usage and better overall performance and response time when Domino was running directly on the hardware.

As this issue is occuring independently from Domino, it is suggested to evaluate the expected load for the server before migrating it under VMware.

When running directly on the hardware, the OS offloads I/O activity to the hardware controller (i.e. SCSI card installed in the server). This requires little CPU cycles as it is a very efficient operation. The same operation under VMware requires the translation of each I/O operation to be performed in software, requiring the use of the CPU. The more I/O is performed, the higher the CPU that is used by the system (kernel time).

High CPU usage by router and poor performance of Domino under VMware


Und weiter:
Domino Server performance troubleshooting best practices

[Tode]

@Ralf: Einen Link habe ich grade nicht parat, nur inzwischen 18 Jahre Erfahrung. Und es war bisher IMMER so (ich betone nochmal: IMMER, und ich hatte das Problem in den verschiedensten Umgebungen, bei den verschiedensten Kunden), dass fehlende Server- Performance und dauerhafte "100%"- Prozessorauslastung am Ende auf schlechte Plattenperformance zurückzuführen waren. Und besonders im VMware- Umfeld hatte ich das gerade kürzlich wieder: Ein Server war praktisch unbenutzbar, weil für die (von einem anderen Server umgehängte) LUN die falschen Treiber / Parameter eingestellt waren. Und auch hier war die sichtbare "Auswirkung" eine 100% Prozessor- Last.

Insofern kann ich nicht mit so nützlichen Links wie Martin dienen (Danke mal wieder dafür), sondern nur mit meiner Erfahrung, und dem, was ich auf dem AdminCamp von absoluten Experten (den englischsprachigen) bestätigt bekommen habe...

[Ralf_M_Petter]

Komisch, in unserer Umgebung verhält sich das genau umgekehrt. Und auch Martins Link bestätigt doch im Prinzip nur, dass die VMWare mit einer hohen Anzahl von IO's ein Problem hat. Wenn ich jetzt das IO Subsystem (mehr Disks, oder SSD statt normale Disks) stärke, werde ich das Problem nur noch verschlimmern statt verbessern. Wir setzten statt VMWare aber auch auf Hyper V und der hat zumindest bei uns dieses Problem nicht. Hier z.B. ein Screenshot, des Taskmanager der VM wenn ich eine 500 MB Datenbank compacte. Man sieht schön wie die CPU Last zunimmt, aber die Kernelzeit trotzdem niedrig bleibt.



@Klass

Ich würde an Deiner Stelle auch mal den Check mit der Kernelzeit machen, ob ihr das Problem mit der VMWare habt.

Grüße

Ralf

[m3]

... und dem, was ich auf dem AdminCamp von absoluten Experten (den englischsprachigen) bestätigt bekommen habe...

Paul?

[Tode]

Ich weiss es nicht mehr genau, aber es war -soviel weiss ich- nicht Paul.. Derjenige hat jedenfalls vor längerer Zeit einen entsprechenden Vortrag gehalten...

[halle]

Ohne mehr über die VM zu wissen können wir eh nix sagen, Klaas meldet sich ja nicht mehr.


Halle

[Klaas]

Hallo Leute,

heute morgen (es war noch nicht wirklich hell) habe ich mich weiter mit dem Thema auseinander gesetzt. Erstmal habe ich die Links die Ihr herausgesucht habt, gelesen. Da mein Admin noch nicht da war, habe ich mich damit beschäftigt was alles durch den Agenten vererbt bzw. geändert wird. Dabei habe ich einen Fehler gefunden und behoben. Somit habe ich morgen erstmal weniger RecallRequest's und damit weniger last.

Zu halle:
Der Agent läuft seit 4 Uhr und ist vor 10 Uhr nicht fertig.
Der Agent ist ein LotusScript Agent (das kann ich trotz versteckten SourceCode sehen)
Betroffen sind 300 Dokument unterschiedlich vielen Unterdokumente. (von ca.20 bis 1300)
Für den Domino-Server wurden extra Raid's angelegt. Die Raid's besitzen alle eigene Platten(12 Stück).
Die Festplatten sind Toshiba 8.9cm (3.5") 600GB SAS2 AL13SEL600 10500rpm 64MB
Die VMware besteht aus 2 Servern und 1 Server steht lediglich den Dominoservern zu Verfügung.
Mit DominoServer meine ich einen "echten" Domino-Server und einen weitern für den Traveller.
Die CPU nutzung liegt zwischen 2502 Mhz und 5400 Mhz je nach Last.
Betriebssystem ist Windows 2012 R2.

Zu pram:
Der Domino-Server wurde auf einem Frischen Windows 2012 R2 installiert. Das Data-Verzeichnis wurde kopiert.
Die Dominoserver-Version blieb unverändert, Domino 8.5.2. FP3.
VMwareTools ist installiert.

Zu Ralf:
das Checke ich jetzt mal

[halle]

Hallo,

die VMware Umgebung hört sich gut an wenn nicht zu viele VM´s auf den Platten liegen die zur gleichen Zeit ordentlich I/O haben.

Hat die Datenbank einen Index, den hast du doch bestimmt bei der Migration gelöscht?!
Kann sein das der Agent einen Index erstellt, wenn er einen Index braucht, und ihn danach wieder verwirft.


Halle

[Micha B]

Windows 2012 wird aber erst mit 8.5.3 FP6 seitens IBM unterstützt.

[Ralf_M_Petter]

Von was für einer VMWare reden wir hier eigentlich?

Grüße

Ralf

[Klaas]

Also grade haben wir, uns die Resourcen im vSphere-Client angeschaut.
Es war nichts los, nicht bei den Festplatten und nicht bei den CPU's.
Daraufhin habe ich den Agent auf dem Server ausgelöst. Zunächst lief dieser bei 0,49% CPU und nach ca. 1 Minute ging er auf 99,04% hoch.

Wieder in die Resourcen geschaut:
Es ist jetzt sichtbar das der Server mehr zu tun hat und die CPU 1 wird auch mit 99 % im vSphere-Client angezeigt. Doch die Latzenszeiten des Raid's sind nicht gestiegen. Auch kann man sehen das die Festplatten in der Nacht (0.00) beim Compact der Mail-Dateien eine viel Höhere Durchsatzrate erreichen.

Den Index habe ich natürlich nicht nach der Migration gelöscht.

Zu Ralf:
VMware VCenter Version 5.1.0
vSphere und VMwareTools sind die aktuellsten


Gruß

Klaas

[Ralf_M_Petter]

Hast du eventuell auch die Möglichkeit den Agent am Client laufen zu lassen? Dann könntest du über das NRPC log schauen, was der Agent so treibt.

Grüße

Ralf

[Klaas]

Hallo Ralf,

die Möglichkeit habe ich, dass kann ich morgen mal machen.

[Ralf_M_Petter]

Eventuell hilfreich

http://petterralf.blogspot.co.at/2013/02/losen-von-notes-performanceproblemen.html