Lausige Performance von Multithreaded Java-Agenten.

Gerade getestet:

Zitat

16.02.2007 03:42:07 PM AMgr: Agent '(juko_ohne_bb3_threaded) juko_ohne_bb3_threaded' is scheduled to run next at: 16.02.2007 03:45:00 PM
16.02.2007 03:42:07 PM AMgr: Agent '(jskoeng_in_bb3_threaded) jskoeng_in_bb3_threaded' is scheduled to run next at: 16.02.2007 03:45:00 PM

Das ist ja lustig! Der startet ja wirklich nur einen Agenten!

Auch nicht schlimm - das lösen wir halt eben durch einen Cronjob, der mehrere "tell amgr run" an den Server schickt.

Zitat

Agent Manager Executive '3': Idle
Agent Manager Executive '1': Running agent '(juko_ohne_bb3_threaded)|juko_ohne_bb3_threaded'
Agent Manager Executive '2': Idle

Aber wieder zurück zum Thema: Das eine sind - nicht näher zu kommentierende - Beschränkungen des Schedulers und das andere - die lausige Performance - ist eine Beschränkung der C-Api - und wie wir nun definitiv wissen - des Clients.

Der Server ist - wie schon gesagt - ein Dual P3 1Ghz mit Linux - der Client das gute Windows XP auf einem Dual-Opteron 2,2Ghz. Und die Performance des Agenten auf dem Client ist - wohlwollend ausgedrückt - unterdurchschnittlich - auf dem Server geht das gerade mal so an.

Hat noch irgendwer irgendwelche Einfälle, was man dem Client noch beibiegen kann, damit das wenigstens so schnell läuft, wie auf dem Server?

Doch noch einen PMR aufmachen? :hammer:

Update: 16:14 Uhr:
Soeben hat's den Server gerissen. Der Agent tut nichts mehr, "sh tasks" zeigt ihn noch an und "tell amgr cancel" jammert, daß der Agent nicht laufen würde.
Ein "quit" auf der Konsole hängt und es riecht verstärkt nach NSD-Logs, die gerade erzeugt werden. So wird das nix. Ich muß doch noch mal die Kundennummer von uns herauskramen und bei IBM jemandem das Wochenende versauen. Trotzdem Danke für die Bemühungen.

a--

Zitat

Update: 16:14 Uhr:
Soeben hat's den Server gerissen. Der Agent tut nichts mehr, "sh tasks" zeigt ihn noch an und "tell amgr cancel" jammert, daß der Agent nicht laufen würde.
Ein "quit" auf der Konsole hängt und es riecht verstärkt nach NSD-Logs, die gerade erzeugt werden. So wird das nix.[...]

Falls mal noch einer von so einem Servercrash gebissen werden sollte:

Es handelt sich hierbei um das leidige FUTEX_WAIT unter der NPTL, welches insbesondere Java 1.4.2 betrifft.

Läßt man den Server mit

export LD_ASSUME_KERNEL=2.4.21

laufen, laufen die Java-Agenten auf dem Domino-Server sauber durch und crashen nicht.

Die Auswirkung auf die Performance ist hier zumindest mit den Java-Agenten nicht wirklich gut meßbar, die mir vorliegenden Meßergebnisse mit abgeschalteter NPTL zwischen 61 und 123 Dokumenten pro Sekunde schwanken. Ein zufällig während dem Agenten anlaufender UPDATE könnte einen durchaus höheren Einfluß auf die Zahlen haben, als die NPTL.

Wie groß ist die zu erwartende Performance-Einbuße auf den Clients durch diese Maßnahme? Hat jemand vielleicht einen Link zu einer Performance-Messung die etwas genauer als die Angabe "huge impact" ist ?

a--