Lotus Notes / Domino 10 > ND10: Administration & Userprobleme

cataloger wird innerhalb von 23 Std. nicht fertig

<< < (3/4) > >>

MLe56:
Sorry, war am WE und die letzten beiden Tage weg, deshalb melde ich mich erst heute wieder.
Wenn der Eintrag "Finished updating database catalog" fehlt, läuft der Catalog_task nicht bis zum Ende durch. Es werden trotzdem 80 - 90% der Einträge täglich aktualisert (sieht man am Änderungsdatum), aber eben nicht alle.
Das Herunterfahren, des Servers macht der Kunde aufgrund keiner geeigneten Backuplösung für Domino. Darauf hab eich keinen Einfluss. Auch die Betriebssystemversion, Windows Server, ist vorgegeben. Auf einem Linux-Server in einer anderen Installation schafft der Server 12.000 Datenbanken in 14 Std.

Matthias

Peter Klett:

--- Zitat von: Pfefferminz-T am 02.10.19 - 10:02:09 ---@Peter: Da bin ich mir nicht so sicher, dass da auch die Einträge aktualisiert werden. Bei ca. 2000 DBs auf einem Mailserver läuft der catalog-Task auch fast 24h...

Kannst Du mal eine Dummy-Änderung an einer ACL machen, ob die sich dann auch im Datenbankkatalog findet?

--- Ende Zitat ---
Wie geschrieben, ich bin kein Admin. Es wurde aber vor ein paar Tagen ein neuer Eintrag in alle ACL aufgenommen, der ist bei einigen Dokumenten im Katalog zu sehen, bei anderen nicht. Hat das irgendwelche Auswirkungen, außer, dass man das da nicht sehen kann?

EDIT: Bei genauerer Kontrolle finde ich keine Datenbank mehr, bei der der neue Eintrag nicht aufgelistet ist, die eine, bei der ich das gesehen hatte, war vermutlich eine ältere, die für die Änderung nicht relevant war. Natürlich finde ich die jetzt nicht wieder ...
In der Ansicht, in der die ACL-Einträge kategorisiert dargestellt werden, sind unter dem User gefühlt (habe nicht gezählt) alle relevanten Datenbanken vorhanden. Gehe daher aus, dass der Prozess durchläuft

Peter Klett:

--- Zitat von: MLe56 am 02.10.19 - 10:29:02 ---Wenn der Eintrag "Finished updating database catalog" fehlt, läuft der Catalog_task nicht bis zum Ende durch.

--- Ende Zitat ---
Da auch der Start des Prozesses nicht geloggt wird, überzeugt mich das nicht wirklich. Vielleicht loggt der das doch woanders, als dort, wo ich suche

CarstenH:
Die Diskussion driftet gerade leicht von der ursprünglichen Frage weg - und anhand einer kleinen Rechnerei seht ihr auch gleich, warum es eigentlich total irrelevant ist wie viele Datenbanken (zahlenmäßig) da so vor sich hin existieren.

Ich habe mir mal aus einer Installation mit 3 Servern, davon 2 im Cluster und aktivem Domain Catalog die Zeiten herausgesucht. Und etwas experimentiert.

Ein Server (ich nenne ihn mal C) dreht nur für den Traveler und langweilt sich zu Tode - hier brauchte der Cataloger ca. 4s für alle(!) 126 DB's (=31,5 DB's je Sekunde, rein rechnerisch).
Dann kommen zwei geclusterte Server mit fast identischem Setting und DB-Umfang, da wird's gleich etwas spannender.
Server A - hier brauchte der Cataloger ca. 6min für 1337 DB's (=3,7 DB's je Sekunde).
Server B - hier brauchte der Cataloger ca. 48min für 1348 DB's (=0,45 DB's je Sekunde).

Es macht auch keinen wirklichen Unterschied ob die Cataloger im Datenbank-Modus oder als Domänenkatalog unterwegs sind - eine kurze Replikation zusätzlich sollte kaum der Rede wert sein.
Rein rechnerisch sind auch die in einem anderen Post erwähnten 16.000 DB's in unter 24h kein Problem - Server C könnte in 24h bei ca 30 DB's je Sekunde problemlos weit über 2.000.000 Datenbanken abfrühstücken und selbst der langsamste der drei (Server B) käme immer noch auf >38.000 DB's(!).
Es kommt also nicht wirklich auf die schiere Menge sondern auf andere Dinge an.
Wir haben hier beispielsweise für den nahezu gleichen Datenbestand der Server A+B einen Unterschied vom Faktor 10! Das kann ja nicht an einer handvoll Datenbanken liegen, oder? ;) Oh doch! Aber nicht an der DB-Anzahl.

Zuerst hatte ich die Last der Maschine B im Verdacht den Unterschied zu verursachen - aber morgens 3 und nachmittags 17 Uhr unterscheidet sich die Laufzeit nur um 1-2 Minuten; also Gedanke verworfen - andere Ursache.

Ich habe mir dann mal den Performancemonitor geschnappt und etwas genauer hingeschaut, was der Cataloger denn da so treibt, was er öffnet und wo er länger braucht.
Zusätzlich habe ich die Protokollierung am Server selbst eingeschaltet (log_catalog=1) um festzustellen ob es außer den angezeigten Datenbanken auch noch andere Zugriffe gibt.

Und au ja - die gibt es. Etwas überraschend für mich trieb sich der Cataloger nämlich nicht nur in den Datenbanken selbst sondern auch länger in den FT Dateien und (weniger überraschend) den ausgelagerten NDX Dateien herum.
Die größte Überraschung aber war, dass 90% der zusätzlich benötigten Zeit auf das Konto von 4-5 Datenbanken ging, in zweien trieb sich der Cataloger geschlagene 10 Minuten herum während er die restliche Masse quasi nebenbei verarbeitet hat.

Mit etwas Überlegung (und etwas Erfahrung aus diversen Performance-Analysen und -Optimierungen) kommt man zu folgenden Schlüssen:

Der Knackpunkt ist nicht die Last des Servers durch Nutzer oder Agenten sondern I/O. Je mehr man die I/O optimiert umso flotter kommt der Cataloger durch.
Im obigen Fall haben Server A+B die FTI und NDX zwar beide ausgelagert aber ratet mal, welcher Server die Verzeichnisse auch auf einem separaten LW verwendet und dadurch u.a. die Disk Queue (Warteschlange für Dateioperationen = I/O-Limit) und den Durchsatz (nochmal I/O) vervielfacht.

Was macht den Cataloger so I/O-intensiv? Er zählt. Er zählt und baut sich dafür scheinbar on-the-fly Query um Query zusammen für ACL, Dokumente, Design-Dokumente, gelöschte Dokumente, Profil-Dokumente, Nutzungsstatistiken (...).
Und in Datenbanken mit Millionen von Dokumenten aller Arten zählt er auch mal etwas länger. Und wenn die DB's und Indizies fragmentiert im Filesystem herumliegen noch länger.
Und wenn der Server auf der gleichen Platte nebenbei noch Compact, DBMT oder andere I/O-intensive Dinge tut noch viel länger.
Und wenn der Cataloger dann dabei noch auf DB's trifft, die lange nicht geöffnet wurden oder deren Zeitpunkt zum Prunen von Löschungen erreicht ist dann triggert er zuerst die entsprechenden Aufräumtasks und wartet so lange untätig.

Und last but not least: falls der Server während dieser Warterei herunterfährt wird er am nächsten Tag an der gleichen Stelle vermutlich wieder warten müssen.

HTH,
Carsten

Peter Klett:

--- Zitat von: eknori am 02.10.19 - 11:47:51 ---Ich habe mal auf meinen Servern geschaut ( V9, 10, 11 )

Überall finde ich die Einträge

Starting update of database catalog
Finished updating database catalog

sowohl im Log, als auch in der console.log

Wenn du auf der catalog.nsf die Aktivitätsprotokollierung aktiviert hast, dann siehst Du dort auch einen entsprechenden Eintrag für den Server.


--- Ende Zitat ---
Da ich der deutschen Sprache soweit mächtig bin, dass ich via Suchen in einem Log nach dem Wort "catalog" (ok, das ist noch nicht mal deutsch) suchen kann, mag ich behaupten, dass bei uns diese beiden Einträge nicht geloggt werden. Habe sogar kurz mit einem unserer Admins gesprochen. Er sagte, dass bei uns eingestellt ist, möglichst wenig zu loggen. Ob das darauf Einfluss hat, wissen wir beide nicht.

Von meiner Seite würde ich die Diskussion zu meinem "Abdrift" auch einstellen wollen. Wir haben nämlich kein Problem, das es zu lösen gibt. Mich hat nur die pauschale Aussage ganz am Anfang gestört, dass mehr als 4000 Datenbanken auf einem Server kritisch seien.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete