CPU Auslastung

[Flafi]

Hallo zusammen,

bisher hatte ich das bekannte Arlamierungstool und Bosmon auf einem alten P3 933 Mhz mit 256 MB ohne Probleme laufen..........

Nachdem ich nun Firemegency gestetet und die Android Funktion auch nutzen wollte habe ich das System umgestellt und neue Hardware eingesetzt.....

Die neue Hardware:

P4 2,66 Ghz 1GB Ram W2K3 Server ( Primergy RX 100 )

.... sollte eigentlich reichen dachte ich.....

Nun mußte ich aber bei heutigen der Probealamierung feststellen das der Server bei der Abarbeitung der Alarmierungen komplett ausgelastet ist und fast 6 Minuten brauchte um alles zu versenden...

Auf der "alten" Hardware mit Alamierungstool dauerte das ganze keine Minute!!!!

Es werden mit Firemergency die gleichen Aktionen ausgeführt wie vorher mit Alamierungstool ( E-Mail und Prowl ) und jetzt zusätzlich bisher 1x Android.

Ist das normal ????

Wie sehen die Hardwareanforderungen aus ????

P.S.: Java ist Version 6 Aktualisierung 27

mfg Frederic

[firEmergency]

Sollte natürlich nicht so sein.
Wie viel Einheiten/Benutzer hattest du denn beim Probealarm alarmiert?

Hattest du die "Einheiten duplizieren" Funktion zur Einrichtung genutzt?

[Flafi]

Waren 10 Einheiten die Alarmiert wurden, jeweils 1x per Mail, einige Iphone und zwei mal per Android..

Edit: Der Benutzer dem die Einheiten zugeordnet sind ist immer der gleiche..


Bei der Einrichtung habe ich es teils "dupliziert" und teilweise per "hand" eingerichtet da bei einigen Einheiten die Personen gleich sind, der Ablauf der ausgelöst wird ist aber immer der selbe. ( Alarmtext -> Smtp -> Iphone -> Android )

Wobei mir beim Testen mittlerweile aufgefallen ist das selbst eine Einheit mit nur 1xMail und 1xIphone im gegensatz zu Alarmierungstool schon "ewig" braucht und er Rechner schwer beschäftigt ist... ( Auch auf andere Hardware mit WinXP sowie Win2k getestet )

[dg76]

Hallo,

ich habe heute firEmergency runtergeladen und installiert. Ich arbeite mit einem Benutzer und ca. 15 Einheiten.

Alle Einheiten haben den selben Alarmablauf. Deshalb habe ich jeweils den Ablauf kopiert. Beim kopieren habe ich festgestellt, dass beim Kopieren vom 1. auf den 2. sehr schnell ist; das wird aber immer langsamer bis er beim 13. oder 14. aussteigt und die Fehlermeldung "Benutzer konnte nicht gespeichert werden" erscheint.

Dort können dann keine Einstellungen mehr vorgenommen werden - die Alarmierung funktioniert dann auch nicht ....

Einmal ist sogar der ganze Benutzer nach der Fehlermeldung verschwunden gewesen, sodass ich alles wieder neu anlegen musste.

Das Programm scheint ein Performanceprobleme zu haben bzw. einen Time-Out zu bekommen.

Kennt jemand den Fehler? Was ist zu tun?

[Hausen]

Hallo zusammen,

also das die Prozessorleistung auf 100% geht habe ich auch. Und ich habe zum testen nur einen Benutzer. Bei mir verzögert sich dadurch die Alarmierung um ca 10 Sekunden.
Anscheinend Summiert sich das dann ja. Das wäre nicht so schön :-(

Ich teste FirEmergency auf einer virtuellen Maschine Windows XP. Diese läuft auf einem Windows Server 2008 R2.

Gruß Hausen

[firEmergency]

Waren 10 Einheiten die Alarmiert wurden, jeweils 1x per Mail, einige Iphone und zwei mal per Android..

Edit: Der Benutzer dem die Einheiten zugeordnet sind ist immer der gleiche..

Bei der Einrichtung habe ich es teils "dupliziert" und teilweise per "hand" eingerichtet da bei einigen Einheiten die Personen gleich sind, der Ablauf der ausgelöst wird ist aber immer der selbe. ( Alarmtext -> Smtp -> Iphone -> Android )

Wobei mir beim Testen mittlerweile aufgefallen ist das selbst eine Einheit mit nur 1xMail und 1xIphone im gegensatz zu Alarmierungstool schon "ewig" braucht und er Rechner schwer beschäftigt ist... ( Auch auf andere Hardware mit WinXP sowie Win2k getestet )

Wird über die Alarm.exe alarmiert?
Wenn ja:
Dauert der manuelle Alarm (über Server-GUI) auch so lange?

Duplizieren:
Siehe unten

Alarm.exe
Siehe unten

Hallo zusammen,

also das die Prozessorleistung auf 100% geht habe ich auch. Und ich habe zum testen nur einen Benutzer. Bei mir verzögert sich dadurch die Alarmierung um ca 10 Sekunden.
Anscheinend Summiert sich das dann ja. Das wäre nicht so schön :-(

Ich teste FirEmergency auf einer virtuellen Maschine Windows XP. Diese läuft auf einem Windows Server 2008 R2.

Gruß Hausen

Gleiche Frage wie oben.

Das die Alarm.exe Probleme machen soll (100% Auslastung) hab ich jetzt schon öfters gehört.
Versuch doch mal die angehängte Alarm.exe. Diese wurde in einer anderen Programmiersprache geschrieben. Hoffe die geht. Bitte um Rückmeldung!!

Hallo,

ich habe heute firEmergency runtergeladen und installiert. Ich arbeite mit einem Benutzer und ca. 15 Einheiten.

Alle Einheiten haben den selben Alarmablauf. Deshalb habe ich jeweils den Ablauf kopiert. Beim kopieren habe ich festgestellt, dass beim Kopieren vom 1. auf den 2. sehr schnell ist; das wird aber immer langsamer bis er beim 13. oder 14. aussteigt und die Fehlermeldung "Benutzer konnte nicht gespeichert werden" erscheint.

Dort können dann keine Einstellungen mehr vorgenommen werden - die Alarmierung funktioniert dann auch nicht ....

Einmal ist sogar der ganze Benutzer nach der Fehlermeldung verschwunden gewesen, sodass ich alles wieder neu anlegen musste.

Das Programm scheint ein Performanceprobleme zu haben bzw. einen Time-Out zu bekommen.

Kennt jemand den Fehler? Was ist zu tun?

Duplizieren:

Finger weg davon, kann ich da nur sagen. Die Duplizieren-Funktion verursacht momentan extreme Speicherprobleme.
Eine Settings-Datei mit 15 Einheiten hat normalerweise einige KB (100KB). Wenn man die Duplizieren-Funktion verwendet, steigt der Speicherverbrauch teilweise bis auf einige 100MB (!) an.
Genauso steigt auch der RAM-Speicherverbrauch enorm an und verlangsamt das System extrem.

Wir wollen diesen Fehler in der nächsten Version korrigieren.

[Flafi]

So habe mal die Alarm.exe ausgetausch und eine neue Einheit angelegt die einen Empfänger (E-Mail) hat.

Habe dann die Einheit mehrmals über das Client- Interface alarmiert und es dauert immer noch länger im Gegensatz zu AT.... werde mal morgen mal weiter testen mit ein paar Iphones......

System läuft momentan produktiv und wenn ich da jetzt einfach mal so was schicke hauen mich morgen ein paar Leute :-))

Was mir gerade noch so aufgefallen ist ich hatte heute auch einige Timeouts bei Prowl und E-Mail Alamierungen und die Alarme sind nicht angekommen :-((

Hoffe das es mit der neuen Alarm.exe morgen besser läuft .... sonst muß das alte System mit AT erst mal wieder ran :-((

Außerdem überwache ich jetzt zum Spaß mal die CPU-Last, mal sehen was da so passiert...

P.S.: Das mit der "riesigen" Settings kann ich so nicht bestätigen die ist 260KB...

[Flafi]

und wenn man Alamierungen braucht bekommt man auch welche...

Heute hat es von 5 Alamierungen bisher 3 mal funktioniert und bei den beiden anderen hatte ich Timeouts bei Prowl sowie auch bei E-Mails.....

Wobei die Zeiten heute besser waren als gestern.....

Das mit der CPU überwachung hat leider nich geklappt ... ( Software nicht gestartet grummel )

Werde mir das mal Überlegen ob ich erstmal zur Sicherheit das "alte" System wieder anwerfe...... und das neue weiter zum testen....

[firEmergency]

So, hab heute mal nen manuellen Alarm nochmal probiert.

Hier ein paar Daten:

Pipeline enthält SMS-Versand (AnySMS) + vorgeschaltetem Alarmtext

Dauer des SMS-Versandes: 350 ms (0,3s!)

Manuelle Auslösung: 17:13:20
Bestätigung des SMS-Versandes: 17:13:20
Beendigung des Alarmablaufes: 17:13:20


Es kann also nicht unbedingt davon gesprochen werden, dass das Tool extrem langsam ist.
Was aber tatsächlich Probleme verursacht, ist die AlarmFMS32.exe.


--------------
Testrechner:
Win7 - 3GB RAM - Core i5

[Flafi]

So habe mich auch mal wenig durch die logs gelesen wo die Zeiten zustande kommen.....

bis zum Versand sprich nach dem Text ersetzen ist alles super ( 0ms ) danach der Prowl Versand Anfang um 13:58:43 bis Ende 13:59:00 nach 16406ms danach kommt E-Mail über Mail-Plugin Anfang 13:59:00 bis Ende 13:59:20 nach 20500ms

sprich für die gesamte Alamierung 37625ms

morgens für die gleiche Alamierung ( selbe Schleife ) 28078ms

danach eine Schleife mit zusätzlich noch Android Empfängern nur 18719ms ...?????

und bei der Alamierung mit den Timeouts bei Prowl bzw. Mail 50891ms

frage mich langsam wo es da klemmt ..???

Ich wollte eigentlich nicht behaupten das das Tool extrem langsam ist!!!! nur kommt es mir so vor das es mit AT schneller ging...

Wobei es sich seit einspielen der neue exe anscheinend schon sehr gebessert hat, denn bei dem ersten wirklichen Probealarm waren es bis zu 6 Minuten bis die letzten Schleifen auf den Handys waren....

Bei AT hatte ich als das Handy wegen der Pushmail klingelte alle auf einmal und jetzt kamen sie halt so nach und nach.. bei Prowl genauso

Und wie ich ja eingangs schon geschrieben habe lief AT bei mir auf nem P3 mit 256MB und die jetzige Hardware ist halt ein P4 2,66 mit nem Gig Ram ( von dem hab ich mir eigentlich mehr versprochen )

[Flafi]

Mal ein Update zum vorherigen Post.....

nachdem gestern bis auf eine Alamierung alles raus ging habe ich heute von 3 Alamierungen 3 mit Timeout jeweils bei Prowl bzw. Android, bei den Mails kamen von 3 nur eine an die anderen beiden auch Timeout....

Das ganze tritt anscheinend auf wenn mehrere Schleifen direkt nacheinander alamiert werden; kann es damit zusammenhängen das alle Einheiten nur über einen Benutzer laufen ???

Oder an der Reihenfolge der Plugins, bei mir monentan Prowl -> Android -> E-Mail..??

@ Affenmensch3 falls Logs interessant sind bitte PM dann schick ich sie per Mail..

[firEmergency]

Also Benutzer ist egal.
Aber zur Optimierung.
So hast du es (oder?):

- Alarmtext
-- Prowl
--- Android
---- Mail

>> Schlecht. Android muss warten bis Prowl fertig ist. Mail muss warten bis Android fertig ist

So sollte die Pipeline aussehen:

- Alarmtext
-- Prowl
-- Mail
-- Android


Du kannst alle 3 (Prowl, Mail, Android) untereinander (nicht ineinander geschachtelt) einreihen.
Dadurch werden alle drei gleichzeitig ausgeführt > schneller

[Flafi]

Ah okay je nachdem wo man es per drag & drop hinzieht .....
nicht einfach nur nach links.... okay war mir so noch nicht aufgefallen.... Danke!!!

aber wodurch kommen die Timeouts..??? Internetanbindung ???

[firEmergency]

Also Time-Out heißt einfach:

Das Plugin arbeitet länger, als es darf. Wie lange ein Plugin arbeiten darf, hängt von unseren (Entwickler) Einstellungen ab.
Da dieses Problem nicht bei allen auftritt, muss es PC/Internet spezifisch sein.
Wir beim Testen zum Beispiel, hatten selten, bis nie Time-Outs.
Die SMS-Plugins machen nur einen einfachen URL-Aufruf. Deswegen kommt es dort eigentlich nie zu Time-Outs.
Bei den anderen, sind wir auf externe Anbieter angewiesen.
Prowl > Prowl-Website
Android > Google App Engine
Mail > Mail Anbieter

Es wäre jetzt zu einfach, die Schuld denen zu geben, da ja beim alten AT, diese Probleme nie auftreten. Dort gab es allerdings auch keine Time-Outs. Das alte AT hat so lange gearbeitet, bis es fertig war.

Für das nächste Update, haben wir alle Time-Outs erhöht.
Aber das löst das Problem natürlich noch nicht. Denn ein Prowl-Aufruf sollte ja nur einige Sekunden dauern.

Bei einer langsamen Internet-Verbindung, kann es aber natürlich durchaus einige Zeit dauern (für jede Push-Nachricht, wird eine eigene Verbindung aufgebaut)

Mal schauen, wie sich das Problem nach dem Update weiterhin verhält.

[Flafi]

Hmmm

Habe mir mal die logs vom Router zu der fraglichen Zeit angeschaut und da hat soweit ich sehe kein anderer den Anschluß benutzt..... und ich sehe im Diagramm nur ein Pik von ein paar kbyte/sek ( so 2-3 )

Der Anschluß ist dort leider nur ein DSL 2000 hat aber mit AT gefunzt....

Idee On:

.....sind in den logs von AT die Zeiten auch drin dann schaue ich da mal nach was er da so hatte, der Rechner ist noch komplett nur halt offline müßte ich dann mal eben vorbei fahren....

Idee Off