Domino 9 und frühere Versionen > ND8: Administration & Userprobleme

Amgr queue Länge/Anzahl erhöhen?

<< < (3/3)

thkn777:
@schroederk
Hmja... hab' eben nochmal geguckt. 9 Instanzen des Amgr sind aktiv.

Es hört sich alles irgendwie nicht schlimm an im ersten Moment...
- 208 agents scheduled,
- 41 agents in eligible queue

Das klingt doch bis dahin irgendwie recht irdisch... und wir haben wenige bis keine "hängenden" Agenten (also Ausführungsstart verzögert, läuft (zu) lange etc.).

(Nebenbei: WIEVIELE Agents dürfen denn nun in der "S" und "E" queue des Domino Servers max. stehen? Meldungen, daß diese überläuft und Planung neuer Agent-Runs deswegen nicht möglich ist, bekommen wir keine.)

ABER: In Summe haben die 9 Amgr Instanzen seit Montag allerdings 116.323 agent runs hingelegt, bei 315422 verstrichenen Sekunden bedeutet das alle 2,7 Sekunden ein Agent. Schon heftig. Sprich: im Schnitt alle 24s war jede Amgr-Instanz wieder dran.

Also JA, der Server steht schon unter Strom...  ;)

Das mit dem zusätzlichen Server - bzw. dem Auslagern der Agents auf einen anderen Cluster-Member - müssen wir wohl in Angriff nehmen. Das wird die Lage sicher entspannen.

Peter Klett:
Ich würde trotzdem das Thema Verringerung der Agenten nicht aus dem Auge verlieren wollen. Mir persönlich ist am liebsten ein einziger Agent, der alle periodischen Aktivitäten abarbeitet (haben wir in der Praxis auch nicht erreichen können, aber vom theoretischen Gedanken geht es in diese Richtung).

Der größte Vorteil darin ist, dass nur wenige Agenten zu überprüfen oder zu aktivieren sind. Kommt eine neue Datenbank dazu, muss sich keiner darum kümmern, dass die darin enthaltenen Agenten laufen.

Als Rahmen benötigt man dazu eine Datenbank, in der alle vom Agenten zu verarbeitenden Datenbanken enthalten sind. In dieser Datenbank läuft der Agent über die Datenbank-Dokumente und holt sich dort heraus, was er mit der Datenbank machen soll.

So etwas auf Basis bereits vorhandener Agenten umzubauen, ist schnell gemacht. Meist reicht es aus, den Inhalt des Agenten in eine Function oder Sub auszulagern, der man die zu verarbeitende Datenbank mitgibt.

Mal als kleines Beispiel:

Alter Agent, der Replizierkonflikte löscht (sinngemäß, können Script- oder Tippfehler enthalten sein)

Dim session As New NotesSession
Dim db As NotesDatabase
Set db = session.CurrentDatabase
Dim col As NotesDocumentCollection
Set col = db.Search (|@IsAvailable ($CONFLICT)|, Nothing, 0)
Call col.RemoveAll

wird umgebaut in eine Sub im neuen zentralen Agenten

Sub ReplizierkonflikteLoeschen (server As String, filepath As String)
   Dim db As New NotesDatabase (server, filepath)
   Dim col As NotesDocumentCollection
   If db.IsOpen Then
      Set col = db.Search (|@IsAvailable ($CONFLICT)|, Nothing, 0)
      Call col.RemoveAll
   End If
End Sub

Ins Initialize des zentralen Agenten kommt etwa folgendes Konstrukt

Dim session  As New NotesSession
Dim db As NotesDatabase
Set db = session.CurrentDatabase
Dim view As NotesView
Set view = db.GetView ("datenbanken")
Dim doc As NotesDocument
Set doc = view.GetFirstDocument
Do While Not doc Is Nothing
   If doc.FlagReplizierkonflikteLoeschen (0) <> "" Then
      Call ReplizierkonflikteLoeschen (doc.Server (0), doc.Filepath (0))
   End If
   Set doc = view.GetNextDocument (doc)
Loop

Das kann man natürlich auch noch schicker machen, aber im Prinzip ist das alles. Nebenbei ist es wohl auch billiger, als je 200 Agenten einen neuen Server daneben zu stellen.

Tode:
@Peter: Das ist ein schöner Ansatz, so lange die Summe der aufgerufenen Agenten dann nicht die maximal erlaubte Ausführungsdauer für einen einzelnen Agenten überschreitet... Im genannten Beispiel scheinen aber sowieso alle Agenten nur wenige Sekunden zu laufen, da wäre das sicher ein gangbarer Weg.

Peter Klett:
Korrekt, da wir mit wenigen Agenten ganz viele Datenbanken verwalten, sind unsere Laufzeiten sehr hoch gestellt (irgendwo zwischen 6 und 8 Stunden, wenn ich mich recht erinnere), aber wir führen damit auch eine richtige Nachtverarbeitung durch mit Reorganisation und Neuberechnung von tausenden Datenbanken und Dokumenten.

Ein denkbarer Ansatz ist aber (den wir so ähnlich auch in einem Fall umgesetzt haben), beim Start des Agenten die Startzeit zu hinterlegen (Profildokument) und vor dem nächsten Schritt (z.B. hier vor der Verarbeitung der nächsten Datenbank) die bisherige Laufzeit zu errechnen. Bei Überschreiten einer vorgegebenen Zeit beendet sich der Agent und schreibt in das Profil einen Verweis auf die nächste zu bearbeitende Datenbank.
Vom AMgr wird er kurz darauf erneut gestartet, schreibt wieder seine Startzeit, liest den Verweis auf die nächste zu bearbeitende Datenbank und fängt mit der an. So kann auch in einem Umfeld, in dem sehr kurze Laufzeiten erlaubt sind, ein quasi Rund-Um-Die-Uhr-Agent realisiert werden.

thkn777:
Hmja... schöne Tips, danke.

Ich habe vor Jahren schonmal eine andere Lösung umgesetzt. Prinzip: Die Agenten in den DB's sind selbst nicht für periodischen Lauf eingestellt. Zusätzlich gibt es eine separate DB, in der per Konfigurationsdokument das Verhalten der Agenten beschrieben wird. In dieser DB läuft dann 1 Agent alle 5 Minuten und führt die konfigurierten Agenten, wenn die Zeit ran ist, auf dem entsprechenen Server aus. (tell amgr run ...) Also sozusagen eine eigene Amgr-Queue-Queue.

Damit sind dann auch abenteuerliche Konfigurationen möglich wie:
- Agent1 soll auf Server1 um 5:00, 5:30 und 6:00 Uhr laufen, dann nochmal um 12:15 Uhr und um 19:30 Uhr.
- Agent2 soll auf Server1 jede halbe Stunde laufen von 22:00 - 06:00 Uhr sowie von 06:00-21:45 alle 15 Minuten auf Server2, Server3 und Server4. Generell kein Agentenlauf sonntags.
- Tip, falls Ihr sowas mal selber baut: per Formelsprache-Evaluierung ermitteln, ob der Agent "jetzt" laufen soll, läßt so einiges an Konfigurationen zu ;) - also auf keinen Fall nur mit einer einfachen Liste arbeiten... irgendwann braucht man das Formel-Gedöhns ja doch ;)
- Für Wartungen kann das Verhalten der Agenten per Konfiguration beeinflußt werden.
- Auch Schwenks der Agentenkonfiguration so recht einfach möglich: altes Queue-Dokument deaktivieren, neues aktivieren.
- usw. usf.

Ich will hier aber nicht mit Kanonen auf Spatzen schießen und Domino - wenn möglich - seinen Job machen lassen. Bzw. ich möchte das erst machen, wenn ich wirklich muss.

Zum Thema "nur ein Agent, der alles macht":
- unsere Situation: Bei vielen Agenten geht es jeweils darum, eine überschaubare Anzahl von Dokumenten zeitnah zu bearbeiten. Das auf einen einzelnen Agenten umzustellen, stelle ich mir schwierig vor.
- "Ausführen im Namen von". Viele Agenten senden Mails mit spezfischen Absenderadressen und mit einem einzelnen "großen" Agenten kann ich diese Agenteneigenschaft nicht dynamisch ändern. Für den Mailversand bliebe mir dann nur noch der mail.box-Weg, der von der IBM nicht offiziell supported wird.
- nochmal "Ausführen im Namen von": was, wenn die einzelnen Agenten nur bestimmte Rechte haben? Und das auch so gewollt bzw. unseren Auftraggebern auch so gefordert ist? Das deckt ein zentraler Agent nicht ab.
- Thema Konfiguration, Protokollierung, Überwachung, Debugging stelle ich mir schwierig vor. Für den Fall, daß Agenten aus 200 DB's mit identischem Design und prinzipiell gleichen Anforderungen zusammengefaßt werden, mag das noch gehen... das ist bei uns aber in dem Ausmaß nicht der Fall.

Da die Agenten in der Regel wirklich sehr kurze Laufzeiten haben, hatte ich auch kein Problem vermutet. Bis unsere Admins mit der Nachricht um die Ecke kamen, daß einige Agents nicht ausgeführt wurden. Wohl, weil die Amgr Queue "übergelaufen" ist... und konfigurieren könne man da nichts.

Ich wehre mich auch so ein bischen dagegen, daß der Domino Server ab einer bestimmten Last einfach Agenten "vergißt". Sollte da nicht eine Fehlermeldung kommen und das Einstellen von neuen Agents in die Queue eine Zeitlang ausgesetzt werden, bis wieder Platz in der Queue ist?

Aktueller Stand:
wir werden wohl einen Teil der Agenten auf anderen Servern laufen lassen.

Ich wünsche ein erholsames Wochenende.

Navigation

[0] Themen-Index

[*] Vorherige Sete