Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: Klaas am 23.04.14 - 11:03:23
-
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.
-
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
-
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
-
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...
-
Wurden die Maschinen migriert oder neu aufgesetzt. Wurden die VMWare Tools auf gen Gastmaschinen installiert?
Gruß
Roland
-
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
-
@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
(http://www-01.ibm.com/support/docview.wss?uid=swg21252786)
Und weiter:
Domino Server performance troubleshooting best practices (http://www-10.lotus.com/ldd/dominowiki.nsf/dx/Domino_Server_performance_troubleshooting_best_practices)
-
@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...
-
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
-
... und dem, was ich auf dem AdminCamp von absoluten Experten (den englischsprachigen) bestätigt bekommen habe...
Paul?
-
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...
-
Ohne mehr über die VM zu wissen können wir eh nix sagen, Klaas meldet sich ja nicht mehr.
Halle
-
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
-
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
-
Windows 2012 wird aber erst mit 8.5.3 FP6 seitens IBM unterstützt.
-
Von was für einer VMWare reden wir hier eigentlich?
Grüße
Ralf
-
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
-
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
-
Hallo Ralf,
die Möglichkeit habe ich, dass kann ich morgen mal machen.
-
Eventuell hilfreich
http://petterralf.blogspot.co.at/2013/02/losen-von-notes-performanceproblemen.html
-
Moin
Schon mal den Support von Gedys darauf angesprochen?
Haben die DB's einen Fulltext index ?
6h für einen Agent ist ja ein bisschen übertrieben.
-
Den Index habe ich natürlich nicht nach der Migration gelöscht.
Ganz schlechte Idee. FT Index auf jeden Fall neu erstellen.
Und die View Indizes am besten auch neu aufbauen.
-
Ich habe jetzt alle Indexes gelöscht. Dabei viel auf das der Index der Adress-Datenbank 1,2 Gb bei 61.000 Doc's fasste. Der Index der Vorgangs-Datenbank fasste bei 345.000 Doc's nur 1,5 Gb bei gleicher Konfiguration. Ich habe daraufhin nochmal alle Ansichten durchgerechnet, ein paar Überflüssige Ansichten gelöscht (ca. 5) und siehe da nur noch 150 MB Index. Jetzt bin ich mal gespannt was das alles heute Nacht bringt.
-
Ich würde auf jeden Fall auch noch kontrollieren, ob die ODS auf die neueste Version hochgezogen wurde. Eventuell wurde das auch vergessen, nachdem auch die Indizes nicht neu erstellt wurden.
Grüße
Ralf
-
Die ODS muss stimmen, da jedes Wochenende ein Compact-C auf jede Datenbank ausgeführt wird.
-
compact -c sollte man meiner Meinung nach nicht generell machen und wenn die richtigen Notes.ini z.B. "create_r85_databases=1" Einträge nicht gesetzt sind wird nach wie vor eine alte ODS verwendet. Am besten die ODS im Administrator kontrollieren.
Grüße
Ralf
-
Es wird auch kein Compact-C gemacht. (Hat mir grade der Admin gesagt)
Die ODS-Version ist 51
-
Und wie läufts jetzt?
-
Ich grüble gerade über den Gedanken, ob es Sinn machen könnte die Volltextindizes in eine Ramdisk auszulagern, sofern die Indizes der Grund für die CPU-Last sind.
Das könnte man ja über den Notes.ini Parameter
FTBasePath=X:\FullTextIndex
bewerkstelligen, hätte allerdings den Nachteil, dass nach jedem Serverneustart die FT-Indizes erst einmal weg sind und ob dies den Server dann wiederum nach einem Reboot nachteilig beeinträchtigt könnt ihr sicherlich besser beurteilen als ich.
-
Nein das wäre keine gute Idee. Wenn genügend Ram vorhanden ist, dann werden die Daten eh sowieso im Cache vorgehalten.
Grüße
Ralf
-
Aha, also Cache = RAM oder wo cached ein Dominoserver?
-
Das macht das Betriebssystem automatisch. Vorteile hätte der Ansatz mit der Ramdisk nur bei Schreibzugriffen. Wobei aber Schreibzugriffe, wenn der Schreibcache richtig konfiguriert und nicht über beansprucht ist, ebenfalls sehr schnell ist?
Grüße
Ralf
-
Hallo Ralf,
es geht so, der Server läuft im Moment ohne Einschränkungen für den User. Gestern haben wir die Hälfte der Ressourcen dem Server fest reserviert. Seit dem ist Ruhe. Aber ob es das war kann ich erst morgen/übermorgen sagen.
-
Hallo,
ich wollte Abschließen zusammenfassen was wir alles gemacht haben.
Wir haben zunächst die Hälfte der Ressourcen der Virtuellen Maschine fest zugewiesen.
Wir haben alle Indexdatein verworfen und neu erstellt.
Wir haben den JVM-Arbeitsspeicher von 1024 auf 3056 erhöht.
Wir haben die Anzahl der zu Aktualisierenden Dokumente reduziert, ohne die Funktion zu beeinträchtigen.
Wir haben bei den Ansichten ausgemistet, Zusammengefasst und Benutzerspezifische Spaltenanzeigen deaktiviert.
Wir haben die Ressourcen-Last begutachtet und festgestellt das im Tagesverlauf keine Spitzen an die Spitzen der Nacht(Importe/Verarbeitung) reichen.
Vielen Dank für Eure Ideen und Vorschläge und Eure Hilfe. Auf manche Sachen hätte ich auch selber kommen können. Es hat Spass gemacht, mal kein Programmiere-Problem hier zu posten.
Wir haben wieder ein schnelles System.
-
Hi Klaas,
wie habt ihr die Ansichten ausgemistet und die Zahl der zu aktualisierenden Dokumente jetzt gemanaged ?
Danke
-
Zu den Ansichten:
zum einen gab es bei uns noch Ansichten welche vom Update der 6er Gedys auf die 7er notwendig waren, zum anderen gab es mehrer Ansichtenpaare welche Sich über eine Kategorie vorweg zusammenfassen ließen. Und dann gab es noch Ansichten welche nie Benutzt wurden. In zahlen bin ich von 260 auf 232 Ansichten runter. Und in der Vorgangsdatenbank ähnlich.
Bei den Dokumenten, Aktualisierungen hatte sich ein Fehler eingeschlichen welcher ca. 150 unnötige Request pro Tag produziert hat. Diesen Fehler habe ich jetzt behoben.