Replikation mit Clients nach Serverumzug langsam

[scifi]

Moin zusammen,

habe ein folgendes Problem:

nach dem Umzug eines Servers (8.5.2 FP1) auf eine andere Maschine (Win2003,frisch aufgesetzt, Notes.ini-Parameter sind nicht verändert worden) ist die Replikation zwischen Clients (8.5.2 / 6.5.6) und diesem Server sehr langsam geworden. Habe verschiedene Clients benutzt, bei allen das selbe Fehlerbild.
Schaue ich auf dem Server, dann habe ich systemseitig kaum Netzauslastung (ca. 1%), CPU-Last etc. Das Öffnen von Datenbanken geht auch normal flott. Nur die Replikation nicht.
Server und Clients haben Gigabit-Anbindung, Kopieren auf Dateisystemebene geht auch dementsprechend: ca. 230 MB große DB = 9 sec., via Notes 1:40 min! Gegenprüfung bei einem anderen Notes-Server im gleichen Netzsegment mit der selben DB = 20 sec.
Hat jemand einen Tipp, wo ich auf dem Domnio-Server hier etwas einstellen kann?

Verregnete Grüße

Sebastian

[Driri]

Ich bin kein Experte, mußte aber direkt an einen Thread von Ulrich denken :

Administrationsprozeß hängt

[scifi]

Hallo Ingo,

danke für die schnelle Antwort!
Das hatten wir vorher auch schon geprüft: der Server läuft als einzigste Maschine auf nem XEN hat eine dedizierte Netzwerkkarte für sich selbst zugewiesen und damit auch eien eigenen Switch-Port... MTU-Size ist auch durchgehend gleich (übereinstimmend mit der Maschine, wo die Replikation normal läuft). Damit scheidet diese Variante aus. 

Sebastian

[stoeps]

DNS? Oder evtl hosts?

Passthrough?

Port encrypt oder compress aktiviert?

[scifi]

Hallo Christoph,

DNS und Hosts funktionieren transparent, Dopplungen oder ähnlich unschönes kann ich auch ausschliessen, habe den DNS-Server mehrfach geprüft (zum Glück darf ich da selber ran, wenn mal ein Notes-Server umzieht  ).

Verschlüsselung und Komrimierung sind allerdings an. Sollte es daran liegen? Diese beiden Optionen sind eigentlich generell bei uns auf 'on' und auf anderen Maschinen ist davon nix zu merken...
Aber: heute is ja eh 'Minimalbesetzung' angesagt, da kann ich das auch mal testen...

Meld mich wieder :-)

Sebastian

[stoeps]

Hi,

ich würde mal zumindest intern ohne die Verschlüsselung testen. Das kann den Delay schon mal um 20% erhöhen.

[m3]

Logging is used for monitoring and troubleshooting problems on both the client and the server. As there are too many logging options to list them all, we have mentioned just a few that are commonly used for troubleshooting certain types of performance issues.

    * Network level debug:

      LOG_SESSIONS=1
      LOG_CONNECTIONS=1
      DEBUG_TCP_ALL

    * Performance problems when performing a particular task or function:

      CLIENT_CLOCK=1
    * Agent/Application logging and debugging:

      LOG_AGENTMANAGER=1
      DEBUG_AMGR=*
    * View/Indexing logging:

      LOG_UPDATE=1
      LOG_VIEW_EVENTS=1

Domino Semaphore Debugging
Notes/Domino uses semaphores and a lock manager (software flags/locks) to ensure that certain tasks complete before others can begin. Many times performance issues occur because a process has a semaphore locked, causing other processes to back up while waiting for access to something. Enabling semaphore debugging is very common in the early stages of working performance issues. NOTE: Semaphore timeouts do not always indicate a performance problem. It is not uncommon for semaphore timeouts to occur on a busy server. For related information, refer to Optimizing server performance: Semaphores (Part 1).

Tips for Enhancing and Troubleshooting Notes 6 Client Performance

[scifi]

Hallo @all,

danke für die Tipps.

Hier mein Feedback:
Es liegt am Datendurchsatz der virtuellen Platten auf dem verbundenen SAN.
Ich habe mit Hilfe von DDM-Probes mal ein bisschen getestet und festgestellt, dass die Zugriffe hier recht zäh sind. Daran kann ich aber nichts tunen.
Eine Verbesserung ist jedoch eigetreten, nachdem ich der Maschine noch eine zusätzliche CPU zugeteilt habe. Erklärbar für mich durch die eingesetzte Verschlüsselung. Dies zeigte im Übrigen deutlich größere Wirkung, als das Abschalten der Verschlüsselung bei gleichgebliebener CPU-Ausstattung (wie von Christoph empfohlen).

Gruß

Sebastian

[eknori]

Was hängt denn für ein SAN daran? Ist Multipath enabled? Wenn ja, ist es auch konfiguriert?
Wir hatten das gleiche Problem mit einer NetApp und NICHT konfiguriertem Multipath. Wurde seinerzeit von "Fachleuten" eingerichtet ... ( soweit zu diesem Thema )

[scifi]

Hallo Ulrich,

Danke für den Tipp. Auch bei uns hat das Teil ein Spezialist (vom Lieferanten) eingerichtet.
Ist ja zugegebenermaßen nicht ganz so trivial. Werde mal versuchen, dazu was rauszukriegen.

Sebastian

[scifi]

Hallo,

habe mich nun also mal mit XEN usw. auseinandersetzen dürfen und tatsächlich auch etwas gefunden. Eine Verbesserung trat nach Behebung folgenden Fehlers ein:  ein LUN auf dem SAN wurde von einer anderen Maschine stark ausgelastet, weil diese nicht genug physischen Speicher hatte wodurch in der Folge auf die "Platte" ausgelagert wurde...fein, das   .

Der Hinweis von Ulrich mit dem Multipathing hat mich allerdings nicht in Ruhe gelassen, so dass ich im XEN-Pool auf verschiedenen Hosts mit und ohne Multipathing getestet habe (immer mit der selben Windows-Maschine und dem fraglichen Domino-Server drauf, das geht durch Hot-Migrate bei XEN recht gut (bei anderen Lösungen sicher auch)).
Fazit: bei eingeschaltetem Multipathing dauert das Erstellen einer Replik reproduzierbar ca. doppelt so lange, wie bei abgeschaltetem Multipathing.
@Ulrich: heisst das für mich, dass das SAN Multipath-mäßig nicht korrekt konfiguriert ist?!?!?

Gruß
Sebastian