Performanceprobleme - Anzeige von Tasks

    Hallo zusammen,
    eine Frage, wenn man sich die Tasks eines Dominoservers anzeigen läßt, werden diese i.d.R. normal angezeigt. Jedoch zeigt einer unserer Server die Tasks mit vorgestellter Nummer an (siehe unten). Kann sein, dass es keine diesbezügliche Rolle spielt, aber der Server hat zeitweise extreme Performanceprobleme (Das Öffnen einer DB dauert dann mehrere Minuten), die aber nur wenige Minuten dauern, dann ist er wieder ganz normal verfügbar. Das ist für Anwender und Administratoren natürlich "etwas" ärgerlich ... An der Hardware sollte es nicht liegen, weil 4 x 3 GHz Xeon und 16 GB Arbeitsspeicher ausreichend sein sollten ...
    Hat vielleicht jemand eine Idee??
    Danke und Gruß.



    (Version 6.5.4)


    So sieht die Konsole aus.


    [0510:0009-085C] sh ta
    [0510:0009-085C] Task Description
    [0510:0009-085C] Database Server Perform console commands
    [0510:0009-085C] Database Server Listen for connect requests on TCPIP
    [0510:0009-085C] Database Server Load Monitor is idle
    [0510:0009-085C] Database Server Database Directory Manager Cache Refresher is idle
    [0510:0009-085C] Database Server Organization Name Cache Refresher is idle
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Perform Database Cache maintenance
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Idle task
    [0510:0009-085C] Database Server Platform Stats is idle
    [0510:0009-085C] Agent Manager Executive '5': Idle
    [0510:0009-085C] Agent Manager Executive '2': Idle
    [0510:0009-085C] Agent Manager Executive '4': Idle
    [0510:0009-085C] Agent Manager Executive '3': Idle
    [0510:0009-085C] Agent Manager Executive '1': Idle
    [0510:0009-085C] Admin Process Idle
    [0510:0009-085C] Agent Manager Idle
    [0510:0009-085C] Statistic Collector Idle
    [0510:0009-085C] Router Idle
    [0510:0009-085C] Directory Indexer Idle
    [0510:0009-085C] Directory Indexer Idle
    [0510:0009-085C] Stats Idle
    [0510:0009-085C] Replicator Idle
    [0510:0009-085C] Indexer Idle
    [0510:0009-085C] Replicator Idle
    [0510:0009-085C] Indexer Idle
    [0510:0009-085C] Event Monitor Idle

    Die vorangestellten Zahlen kommen durch einen Debug Parameter der Debug_ThreadID=1 heisst. Wenn Du den wieder auf 0 setzt, verschwinden die Zahlen wieder.
    Zu deinem Problem: Ist das bei allen DBs oder nur bei manchen? Sind die was besonderes? Viele Änderungen, ziemlich groß, viele Views?

    Hallo und danke,
    es handelt sich um zwei recht große Datenbanken mit 500.000 bzw. über eine Mio Dokumenten. Es gibt auch viele Ansichten, die auch öfter indiziert werden, da sehr viel Traffic zwischen diversen Servern besteht. Ich habe den VT-index von sofort auf stündlich gesetzt, damit nicht zu viel Performance verloren geht. Natürlich könnte auch die Replikation eine Rolle spielen, aber eigentlich sollte der Server es schaffen ... Wenn Du noch eine Idee hast, wo ich vielleicht etwas drehen könnte, damit die Perfomance noch etwas besser wird, ich wäre dankbar ...
    Gruß.

    Der Volltextindex ist da eher vernachlässigbar.
    Nur wenn in diesen Datenbanken viel Fluktuation ist, dann muss ja der View Index beim öffnen jedesmal neu aufgebaut werden. Und bei einer großen Anzahl von Dokumenten, vielleicht noch mit komplexen View Formeln oder sogar irgendeiner Zeitfunktion in der Select Formel dauert das Aufbauen des Index eben so lange.
    Und da arbeitet dann der Client und nicht mal der Server

    Hallo Taurec, hallo Muerte,
    danke für die Antworten, ich denke, dass auch die Replikation eine Rolle spielen könnte.


    Mit den Indizes, das läßt sich nachvollziehen, aber warum dauert es so lange, wenn auch nur ein einzelnes Dokument geöffnet wird (oder eine Schaltfläche gedrückt wird)? Ich den "Downzeiten" ist einfach nix drin, dass Öffnen der DB dauert 5 Minuten und das Öffnen eines Dokuments dauert auch schon mal 3 Minuten. Es sollte somit vielleicht doch noch ein anderes Problem zusätzlich sein? Vielleicht noch eine Idee? Wenn ich am Server bin, dann ist die CPU Last bei 30 % und es werden ca. 1,5 GB Arbeitsspeicher verbraucht, das ist ja nicht viel ...


    Gruß und Dank.

    Wie gesagt vermute ich das hängt mit dem Aufbau der Views und Masken zusammen.


    So als Beispiel eine Ansicht die eine Zeitfunktion in der Selectformel hat braucht schon bei wenigen Dokumenten relativ lange, bei vielen vervielfacht sich die Zeit.
    Wenn jetzt in der Maske noch ein @DBLookup auf so eine Ansicht erfolgt, dann muss die beim Öffnen des Dokumentes nochmals aktualisiert werden.


    Dadurch könnten sich deine langen Öffnungszeiten erklären.


    Woran es wirklich liegt wird wohl nur eine Analyse des designs der Anwendung ergeben können

    Danke, mein momentanes Problem ist, dass es sich um ein verstecktes Design handelt und ich somit ausnahmslos spekulieren darf... Naja, ich habe die Performance gerade mal probiert, es scheint, dass es dann schwer wird, wenn der Indexer auf dem Server läuft. Es ist aber für eine verbindliche Aussage noch zu früh. In jedem Fall schon mal vielen Dank für die prompten Antworten.


    Gruß aus Hamburg.

    Moin, moin,


    nach mir bekannten Aussagen hat LN6 ein erhebliches Problem mit internen Lookups aufs Adressbuch.
    So auch das mehrere Indexer u.U. auf ein und dieselbe View loßlaufen um diese zu aktualisieren.


    Was sich darin zeigt das die Performace des Servers deutlich in die Knie geht bis hin zum "stehen bleiben" des Servers.


    Mit 6.5.6 bzw. 7.0.2 soll dies behoben sein.
    Dann soll die nächste Task die loßläuft erst mal checken ob da nicht schon eine zu Gange ist, und ggf. dann einfach warten bis diese abgearbeitet ist.


    Gruß

    Zitat


    malmsta schrieb:
    ...
    nach mir bekannten Aussagen hat LN6 ein erhebliches Problem mit internen Lookups aufs Adressbuch......


    Mit 6.5.6 bzw. 7.0.2 soll dies behoben sein.....


    Hast Du dazu ne SPR# ? Ich kann in der Fixlist zu 6.5.6 bzw. 7.0.2 nichts passendes finden ?