Amgr queue Länge/Anzahl erhöhen?

[thkn777]

Hallo zusammen,
ich werfe den Suchmaschinen dieser Welt anscheinend die falsche Fragen in den Rachen, bitte helft mir mal auf den rechten Weg:

Auf einem Server laufen sehr viele periodische Agenten in sehr kurzen Abständen. Größenordnung 300+ Agenten alle 5 Minuten, 200+ Agenten alle 30 Minuten. Weitere Agenten, die einmal täglich laufen.

Problem: die Queue des Amgr ist irgendwann "voll" und einige Agenten kommen einfach nicht mehr dran. Das hat nichts damit zu tun, daß der Server es von der Last nicht schaffen würde. Die Agenten selbst laufen jeweils nur ein paar Sekunden. Es sind 10 Instanzen des Amgr aktiv.

Agenten, die eigentlich in der Queue stehen sollten, sind nicht zu finden... es scheint eine maximale Anzahl an Agenten zu geben, die "Schlange stehen" dürfen.

Mein Ziel: die Länge der Queue (also die maximale Anzahl der Agenten, die dort verwaltet werden) erhöhen. Oder eine andere Lösung admin-seitig finden, damit einfach alle Agenten mal dran kommen.

Wie geht Ihr mit derlei Anforderungen um?

[alexhe]

Hi ,

ich eröffne eine PMR und frage den Hersteller

[Driri]

Was sind denn das für Agenten bzw. was für Anwendungen ?

OoO kann man mittlerweile über einen Service abfackeln. Für einige Gruppenkalender gibt es statt der Termin-Sammel-Agenten Server Tasks, die das übernehmen.

Worauf ich hinaus will: Untersuchen, ob sich die Menge an Agenten reduzieren läßt.

[thkn777]

@alexhe
Das ist ja nett von Dir! 
Ich habe schlechte Erfahrungen mit PMR's - meine laufen immer ein paar hundert Tage und dann gibt die IBM auf  vielleicht hast Du ja mehr Glück! 

P.S. Ich weiß, daß das kein ernstgemeinter Vorschlag war...


@Driri
Jaaaaa.... guter Ansatz! /thumbsup
An der Stelle überlege ich auf jeden Fall, was wir sinnvoll machen können. Aber im Moment geht das nicht mit dem reduzieren bzw. nicht mal eben einfach so.


Unter diesen Voraussetzungen... andere Ideen?

[alexhe]

Das war ein ernstgemeinter Vorschlag. Du bist Kunde, du zahlst einen jährlichen Wartungsvertrag und wenn du einen Call mit Prio 1 aufmachst , dazu schreibst, dass du gleich an den Second Level weitergeleitet möchtest und nicht mit First Level  sprichst, dann sollte das keine hundert Tage dauern.

Sollte das nicht fruchten, mach einen Complaint auf.

[schroederk]

Ich weiß nicht, was ihr für Probleme mit PMRs bei IBM habt.
Selbst bei Tickets mit Prio 4 bekomme ich spätestens noch am gleichen Tag Antwort, meist sogar innerhalb der nächsten 2 Stunden.
Und selbst bei dem längsten Ticket, das mal über ein paar Wochen lief, gab es beinhae täglich Antworten oder Rückfragen.

Ich kann mich über viel beschweren, aber über den Support nicht.

[WernerMo]

Ich weiß nicht, was ihr für Probleme mit PMRs bei IBM habt.
Selbst bei Tickets mit Prio 4 bekomme ich spätestens noch am gleichen Tag Antwort, meist sogar innerhalb der nächsten 2 Stunden.
Und selbst bei dem längsten Ticket, das mal über ein paar Wochen lief, gab es beinhae täglich Antworten oder Rückfragen.

Ich kann mich über viel beschweren, aber über den Support nicht.

Vielleicht liegt das ja an der Qualität der Tickets (das kenn ja jeder selbst)
Ein Ticket in Englisch mit genauer Beschreibung des Fehler, zugehörigen Logs etc. kann eben leichter reproduziert werden als "... geht nicht (mehr)..."
Das hat meiner Meinung nach weniger mit Glück zu tun ...

Gruß aus Mittelfranken
Werner

[schroederk]

Vielleicht liegt das ja an der Qualität der Tickets (das kenn ja jeder selbst)
Ein Ticket in Englisch mit genauer Beschreibung des Fehler, zugehörigen Logs etc. kann eben leichter reproduziert werden als "... geht nicht (mehr)..."
Das hat meiner Meinung nach weniger mit Glück zu tun ...

Vielleicht habe ich gleich von Anfang an instinktiv alles richtig gemacht...
Ich schreibe die Tickets grundsätzlich in englisch. Dann gibt es schonmal keine Übersetzungsfehler vom Level 1 zu Level 2.
Level 2 benötigt das Ticket dann sowieso in englisch.
Vielleicht waren meine bisherigen Probleme auch zu trivial? 

Mir ist aber schon aufgefallen, dass ich fast immer mit den selben Personen bei IBM zu tun habe.

[thkn777]

/offtopic start
Falls das Thema IBM Support generell einen Thread wert sein sollte, dann sollten wir einen starten und da das Thema weiter diskutieren. Um kurz auf Eure Anregungen und versteckten Fragen einzugehen:
- ab 2nd level läuft eh alles in englisch, zuweilen gibt's aber auch Kontakte zu IBM-Experten aus Deutschland... mit denen spare ich mir dann den "Englisch-Umweg"
- die Daten und Informationen, die wir der IBM liefern, sind sehr detailliert und sehr umfangreich. Das Logging ist teilweise so brachial, daß die Server davon in die Knie gehen oder Server und Clients dramatische Performanceeinbußen erleiden.
- Telco's und Webkonferenzen gibt's obendrein
- mit einem lapidaren "geht nicht" wende ich mich nicht an den Support 
/offtopic ende

Hat jemand zur eigentlichen Frage noch eine Anregung für mich?

[schroederk]

Zum Topic:
Ich befürchte, dass sich die Anzahl der gleichzeitig laufenden Agents nicht erhöhen lässt.

Beim IBM Knowledge Center steht:

You can relieve a heavily loaded Agent Manager by allowing agents to run concurrently. To do this, modify the "Max concurrent agents" field in the Server Tasks/Agent Manager section of the Server document. Values greater than 1 allow more than one agent to run at the same time. Valid values are 1 through 10. Default values are 1 for daytime and 2 for nighttime.

Inbesondere das "Valid values are 1 through 10".

Wenn sich die Anzahl und Laufzeit der periodischen Agenten nicht deutlich reduzieren lässt, dann bleibt wohl nur ein zusätzlicher Server 

[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.