Ansicht wird ständig aktualisiert

  • Guten Morgen,


    ich habe hier einen Effekt, der äußerst merkwürdig zu sein scheint. Ein Anwender beklagt, dass diverse Ansichten aus einer Standard Mail Datenbank, wie Inbox, Sent usw... ständig aktualisiert werden.


    "Diese Ansicht wird aktualisiert. Sie wird sofort nach Abschluss der Aktualisierung angezeigt. Sie können während der Aktualisierung der Ansicht mit anderen Fenstern weiterarbeiten".


    Die Lotus Notes Version beläuft auf 8.5.3FP6. Die Anzahl der Dokumente in der DB beläuft sich auf ca. 150.000


    Ich habe bereits lo fixup -J -F mail/..... ausgeführt und auch ein lo updall -R mail/.....


    Beide Befehle brachten temporär Erfolge, jedoch kommt nach 2-3 Tagen wieder obige Meldung in der Ansicht auf.


    Habe ich etwas nicht beachtet?


    Vielen Dank.
    Beste Grüße
    Deny

  • Hey Deny,


    wieviele Dokumente enthalten die Ansichten, die neu aufgebaut werden ? Ich finde 150k Dokumente "ein bisschen viel" . Unser "HeavyUser" kriegt gerade einmal 40k Dokumente zusammen.



    Behauptung: Dokumentenanzahl reduzieren

  • Ist die View nach einer der Datumsspalten sortiert?

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • Ok,


    @alexhe - das ist schon mal eine Aussage 150.000 Dokumente = viel ;) die Ansichten selber werden wohl so (Inbox / 25000) und (Sent 17000) haben. Der Rest ist in Ordnern abgelegt.


    @RockWilder - ja die Views ($Inbox und Sent) sind nach Datumsspalten sortiert.


    Falls die Anzahl der Dokumente hier durchaus diese Thematik verursachen sollten, dann werde ich über kurz oder lang diese "große" DB als Archiv DB abstellen und eine neue leere Datenbank erzeugen lassen. Was meint Ihr dazu?


    Vielen Dank.
    Beste Grüße
    Deny

  • Ich frage mich immer wieder, warum man seine Inbox so vollmüllen lassen muss. Geht mir echt nicht in den Kopf.


    Die Sortierung nach Datum kann durchaus das Problem sein. Vor allem, wenn die neueste Mail grundsätzlich zuoberst angezeigt werden soll. Was kein Wunder ist, da man ansonsten in diesem Müllhaufen keinen Überblick mehr hat. Soll das neueste Dokument oben stehen, muss der Ansichtsindexer permanent umschaufeln. Sprich: alle vorhandenen Dokumente um eine Position in der Liste nach hinten verschieben und vorne dran das Dokument einfügen. Es liegt in der Natur der Sache, dass das ziermlich IO-trächtig ist und ab eines gewissen Müllaufkommens dann natürlich auch CPU- und RAM-belastend. Wenn jetzt ganz unglückliche Umstände zusammentreffen, wird der Indexer mit der Umsortierei nicht fertig, wenn das nächste Dokument eintrifft.


    Ein Updall macht den Index schick, ab dem Zeitpunkt muss der Client nur noch die Deltas verarbeiten. Laufen die Deltas zu weit auseinander, kann es zu dem von dir beschriebenen Zustand kommen, dass es en paar Tage später wieder "mackt". Tatsächlich "mackt" es da aber nicht, sondern der Client versucht nur sein Bestes, während der User ihm permanent Knüppel zwischen die Beine wirft.
    Die 150.000 Dokument in der DB selbst stellen kein großes Problem dar, solange die Ansichtssortierung nicht misshandelt wird. Auch die 17.000 - 25.000 Dokumente in $Sent, bzw. in $Inbox (letztere ist keine Ansicht!!) dürften kein Problem darstellen, wenn der User sich einfach mal am Riemen reissen, bzw. der Admin ihm amtlich die Leviten lesen würde.
    Das Problem ist ein klassisches Layer-8-Problem. Im Gegensatz zu den meisten Layer-8-Problemen gibt es hierfür aber eine technisch einfach zu realisierende und absolut nachhaltige Lösung: Spaltensortierung nach Datum aus dem Template rausoperieren. Dafür gibt es ohnehin keine wie auch immer geartete Notwendigkeit. Und wenn der User dann erstmal seitenweise nach unten scrollen muss, um an seine aktuellen Mails zu kommen (ich wette mal: knapp die Hälfte davon sind eh ungelesen?), dann räumt er von selbst auf.

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • Guten Morgen,


    vielen Dank für die ausführliche und verständliche Erläuterung, hilft bei meiner weiteren Entscheidungsfindung ungemein. Hihihihi jaja das Layer-8 Problem. Immer wieder interessant, wie man ein System ausreizen und damit ein entsprechendes Verhalten hervorrufen kann.


    Beste Grüße
    Deny

  • Auch wenn die Darstellung des Indexer- Tasks in RockWilders doch stark vereinfacht ist, stimme ich ihm von der Aussage her größtenteils zu: Eine solche Datenbank ist IRRSINN.


    Was sagen denn die Statistiken zu den Update- Queues. Ich bin mir ziemlich sicher, dass dort die Ursachen zu suchen sind.


    In einem Standard- Server, an dem man nicht "getuned" hat, läuft EIN Update- Task, und der ist zuständig für Ansichtsindizes UND Volltext.


    Wenn Du jetzt eine solche Monster- Datenbank hast, die den Indexer mit jeder Mail die eingeht stundenlang beschäftigt (Schau Dir mal im Adminclient mittels "Ansichten verwalten" an, wie gross die Ansichtsindizes in der Datenbank sind), dann laufen zwangsläufig andere Updates auf... und wenn die nächste Mail einngeht, dann muss auch die "Monster"- Datenbank warten...


    Stelle mal die Updaters in der ini auf Anzahl Prozessoren, und aktiviere einen eigenständigen Volltext- Thread über UPDATE_FULLTEXT_THREAD=1


    Dann beobachte die Statistiken für die Updater, ob sie jetzt hinterherkommen. Die Pendling- Listen sollten immer im niedrigen einstelligen Bereich sein, sonst hast Du Stau...

  • @Tode
    Wir haben unseren Domino auf ner VM mit 1 x virtuellen Socket und 4 Cores pro Socket. Das bedeutet ich stelle meine .ini folgendermaßen ein.


    UPDATER = 4
    UPDATE_FULLTEXT_THREAD=1

  • Du sollst nicht einfach INI- Einträge setzen (auch wenn das die Werte wären, mit denen ich anfangen würde): Analysiere die Statistiken (Admin- Client - Server - Statistik - Update - PendingList und PendingList - Max),
    und prüfe, ob es nötig ist.


    Wenn es denn nötig ist (PendingList hoch), dann setze die Werte und starte den Server neu.


    Wenn Du erst mal prüfen willst, ob das überhaupt was bringt, dann setze den UPDATE_FULLTEXT_THREAD=1 Parameter, und gib an der Console "tell update quit" und "load update" ein, dann hast Du schonmal einen extra UPDATE- Thread. Wenn Du dann nochmal "load update" eingibst, hast Du zwei Updater, dann kannst Du beobachten.


    Wenn Du den Server neu startest, wird aber nur ein Updater gestartet.


    Du kannst so lange "load update" eingeben, bis Du bei der gewünschten Zahl updater angekommen bist. Dann beobachtest Du die PendingList der einzelnen Threads. Sobald die (bei voller Serverlast, also tagsüber) auf niedriegen Werten nahe 0 bleibt, hast Du den richtigen Wert für die Anzahl Update- Threads gefunden und trägst den für den nächsten Neustart in die ini als UPDATER=x ein...

  • Guten Morgen,


    also bisher muß ich sagen, dass meine PendingList mehr 0 als > 20 war. PendingList.Max ist auf 70. Über sh stat update habe ich das ganze einfach hin und wieder beobachtet. Die .ini Werte habe ich noch nicht übernommen. Ich werde es noch über den Tag prüfen. Ansonsten suggeriert es mir, dass es soweit in Ordnung ist.


    Beste Grüße
    Deny