Domino 9 und frühere Versionen > ND6: Administration & Userprobleme
Cluster: Performance Probleme
Tode:
Ausgangslage:
2 Server mit Windows 2003, Domino 654 FP3 LP Deutsch,
ca 550 User
Der "alte" Server (Dual Proz 3,8GHz, 3,5GB RAM) hat bis vor kurzem ohne Probleme die Last alleine getragen, jetzt ist ein weiterer Server (nahezu identische Leistung, nur etwas neuer) dazu gekommen.
Beide wurden geclustert um Ausfallsicherheit zu erreichen.
Beide haben 2 Netzwerkkarten, unterhalten sich über Ihren Cluster-Port miteinander und über die andere Netzwerkkarte mit den clients.
Seit der Clusterung ist die performance auf dem "alten" Server streckenweise unter aller Sau:
Im Log erscheinen (jeden Tag etwa zur selben Zeit, 9 Uhr morgens und ca. 14:00) viele viele Meldungen, dass er "load balancing off of Server1..." macht, und das öffnen von Datenbanken (speziell von einer sehr grossen CAS- Db (3,5GB) geht gar nicht mehr.
Nach ca. 2-5 Minuten hat er sich wieder gefangen, und alles sieht aus wie vorher.
Zu diesen Zeiten
a) laufen zwar Agents, aber immer unterschiedliche
b) zeigt der Server-Availability-Index eine Verfügbarkeit von über 50 (unser Threshold) an.
c) ist die Prozessorlast (Task-Manager) nicht aussergewöhnlich hoch
d) läuft kein Indexer o.ä. (sh tasks), der das erklären könnte
e) zeigt die statrep.nsf keine aussgerwöhnlichen Werte in den Statistiken zu Platform, Cluster, etc. (haben wir kurzfristig auf 15min. eingestellt)
Der Server scheint einfach nur von aussen "tod" zu sein, und kurz darauf ist wieder alles eitel Sonnenschein. In diesen Perioden lässt sich von der oben erwähnten Datenbank nicht einmal die DB- Eigenschaftsseite öffnen (Netzwerkoperation wurde nicht in angemessener Zeit abgeschlossen), während andere Datenbanken teils ohne Probleme funktionieren.
Die DB als Ursache wurde schon ausgeschlossen: Sie wurde schon komplett gelöscht und vom Clusterpartner als neue Replik neu erstellt.
Hilfe....
Irgend ne Idee, wie ich dem ganzen auf die Schliche komme ?
Thanx
Tode
knoedel0815:
Des Rätsels Lösung würde mich auch interessieren.
Wenns aber immer zu bestimmten Uhrzeiten auftritt - gibts vielleicht Verbindungsdoks, die während der Zeiten mit Replikationen loslegen - ggfls. auf anderen Servern?
Wie sieht denn die Netzlast aus?
Was sagt denn "sh ta" bzgl. gerade laufender Agenten (obwohl eigentlich schon beantwortet)?
Gibts evtl. auf OS-Ebene Tasks, die viel CPU ziehen?
Fragen über Fragen...
smoki:
Also so ein ungelöstes Phänomän hatte ich auch mal und es ist von selbst verschwunden, aber der Grund würde mich auch interessieren! 8)
Vielleicht verliert er manchmal seinen Default-Port für die Anwender??
Ist die Standard TCP Port auf einer IP genagelt oder dynamisch (vom OS?)... Ich würde diesen auf die IP festlegen! (notes.ini)
TCPIP_TCPIPAddress=0,aa.bb.cc.dd:1352
Gruss
Chris
Driri:
Hast Du schon mal geschaut, ob das evtl. gar kein Domino-Problem ist ? Evtl. rennt da zu den Zeiten ja irgendwas auf OS-Ebene los ?
Tode:
Danke für die vielen Anregungen, aber leider hilft das alles nicht wirklich weiter.
Ich verfolge das ganze täglich, und habe jetzt folgende (spärliche) Zusatzinformationen sammeln können:
1. Ich konnte das Failovern verringern, indem ich den SERVER_TRANSINFO_RANGE auf 25 hochgesetzt habe, laut einem KB- Eintrag ist derr Standard- Wert von 6 für aktuelle Server viel zu gering.
2. Ausserdem habe ich einen Event- Generator erstellt, der vom neuen Server die Performance des alten Servers per öffnen einer grossen DB überwacht, und der zeigt, dass der Server relativ häufig "beschäftigt" ist (teilweise alle 10 Minuten)
Jetzt eine wirklich neue "Spur": Wann immer der Server1 (alt) für den Server2 (neu) nicht /nur langsam erreichbar ist, laufen kurz vorher Agenten an, die über ODBC Daten aus einer AS/400 auslesen. Kann so ein ODBC- Zugriff das Netz so zumachen, dass ein Server nicht mehr antwortet ?
Ich bin so langsam am verzweifeln und schon fast so weit, den Cluster wieder abzuschalten, damit hier wieder einigermassen "Normal" gearbeitet werden kann.
Irgendwelche Tipps wären toll...
Tode
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln