Wofür brauche ich die Reaggregation? Ich habe es bisher nur genutzt wenn ich von Standart auf Zähler, oder umgekehrt, geändert habe.
GeTapatalk(t) mit meinem Galaxy Tab 10.1N
Hi Horst, das braucht man spätestens dann, wenn man in einer fortlaufenden Datensatzreihe Datensätze löscht. Denn dann stimmen die Aggregate (Stundensummen, Tagessummen …etc.) nicht mehr. Um diese zu korrigieren, startet man eine reaggregation. Die macht nichts anderes, als die Aggregatwerte -basierend auf der neuen Datensatzreihe erneut zu berechnen und in die DB zu brennen. Ansonsten basieren die Aggregate nach wie vor auf der alten, nicht mehr vollständigen Datensatzreihe und sind damit nicht korrekt.
Wenn man das macht, hat man plötzlich auch wieder korrekte Anzeigen in Graphen, Variablen (insbesondere Zähler-Variablen) etc.
Nachtrag: auch ein mit der Brechstange beendetes IPS kann zu inkorrekten Aggregatwerten führen, u.A. deshalb mache ich eine Reaggregation etwa alle 3 Monate
Hallo RS,
very good job!!
Zukunftsfrage: Es war doch nicht Dein Ernst den FF von der Liste der supporteten Browser zu nehmen?
Feedback: Aktuell läufts bei mir nur mit dem neuesten Chrome (ich mag Chrome nicht) sauber. Der FF ind IE haben Probleme mit dem Scrollen.
Danke Raketenschnecke,
dann sollte ich wohl mal meine Variablen reaggregieren und mein dummes Gesicht Posten wenn ich sehe, wir meine Grafiken plötzlich aussehen.
Um Deine vorangehe Frage zu beantworten, ich würde dann einen Button zur Auslösung oder noch besser eine Möglichkeit zur Einstellung eines Datum/ Uhrzeit um die Reaggregation zu einem Zeitpunkt wo ich evtl. nicht zu hause bin laufen zu lassen.
GeTapatalk(t) mit meinem Galaxy Tab 10.1N
Hi All,
auf Grund des „regen Interesses“ (:rolleyes:) hab ich soeben eine neue Version online gestellt:
Download via Projekt-Homepage: http://www.raketenschnecke.net/2012/11/20/rs-db-analyzer/
Changelog:
2012-12-01 V2.3Fixes
* Option „Logging einschalten“ (Variablen-Steckbrief) bei vewaisten Variablen entfernt
* fehlerhafte Darstellung leerer Tabellenzellen in FF und IE fixed[b]Features[/b] * Umstellung auf deutsches Zahlenformat (Datum, Zahlen), incl. Sortierung * Einbau RS Aggregation-Manager für Variablen (via WFE-Reiter "ReAgg-Manager") * Tabellen merken sich die aktuell gewählte Sortierung (auch bei Refresh)
Wesentliche Neuerung: der [b]Aggregations-Manager
[/b]Mit V2.3 gibt es einen Aggregation-Manager, mit dessen Hilfe eine Reaggregations-Queue erstellt und gemanaged werden kann. Man erstellt quasi auf Basis der Variablen-Übersichtstabelle via Checkmark-Klick eine Auswahl (oder alle) Variablen und schickt diese in die Bearbeitungs-Queue. Der Aggregation-Manager arbeitet diese dann vollständig ab. Die Queue kann während des Reaggregations-Prozesses ergänzt, verkürzt oder gelöscht werden. Ebenso erhält man Infos über die voraussichtliche Dauer der Reaggregation (bei mir würde eine vollständige Reaggregation ca 65h (!) dauern) – so fällt eine Planung der ReAgg-Queue wesentlich leichter.
Die Abarbeitung der Queue lässt sich via Button im WFE in den Pause-Modus versetzen, falls wichtige IPS-Aktivitäten anstehen. Anschließend kann die Abarbeitung fortgesetzt oder die Queue ganz gelöscht werden.
feel free, have fun and reaggregate it!
Hallo Raketenschnecke,
habe gerade das Update installiert, ging wie immer Problemlos. Allerdings bei der Geschwindigkeit wie Du die Updates zur Verfügung stellst kommt man ja fast nicht hinterher
Eine Fehlermeldung hatte ich nach ausführen von “Config/User-Config”
IPS-Err-PHP 2012-12-02 07:47:53.184 Warning: Division by zero
Error in Script C:\IP-Symcon_2_0\scripts\53024.ips.php on Line 48
Ist diese Zeile:
$InvReAggAvg = $ReAggPerformance['Value'] / $ReAggPerformance['Records'];
in VarKeyNote-Generator.
Muss ich mir da Gedanken machen?
Hallo Horst,
nein, das ist kein Problem (nur eine nicht abgefangene Fehlermeldung, wenn noch nie eine Reaggregation durchgeführt wurde), ist mir durch die Lappen gegangen.
Den Fehler kann ich bestätigen. Tool läuft aber.
EDIT: zu spät… 
Grüße
galleto
wenn Euch das zusehr nervt, könnt ihr zwischenzeitlich (bis zum nächsten Update) in der Zeile drüber das hier einfügen (austausch der alten Zeile gegen die Neue):
if(isset($ReAggPerformance['Value']) && ($ReAggPerformance['Records'] > 0))
Hallo RS,
super Tool:) respekt:eek:
Ganau das Problem ist mir schon länger ein Dorn im Auge.
Meine DB hat 131 geloggte Var und schon fast 2,5Gb.
Das System läuft super solange ich die DB nicht anrühre.
Jetzt hatte ich gehofft dass es mit deinen Tool einfacher wird.
Leider bleibt auch mit deinem Tool mein System stehen. (langsame Abarbeitung im Meldungsfenster)
Gibt es eine „Mindest-Systemleistung“?
Edit: Muss mal meine Signatur ändern.:rolleyes: Mittlerweile habe ich 2Gb RAM
Hallo Bussard,
erstmal vielen dank für die Rückmeldung
zu Deinem Problem:
was genau meinst du mit „bleibt mein System stehen“? -> füllt sich die PHP-Task-Queue und werden die Tasks evtl. sogar rot?
=> dann ist ziemlich sicher deine DB korrupt. hier hilft nur Neuaufbau/Datenbankwiederherstellung (wir hatten in diesem Thread schon 5 solcher Fälle).
zur Performance:
bei mir liegen die Werte zwischen 30-60 Records/Sekunde. Je weniger Records eine Var hat, desto geringer die Performance. Bei sehr wenigen Records kommen dann schonmal ziemlich unsinnige Werte wie 0,1 raus. das kann man aber getrost ignorieren (das ist systembedingt)
Ja so ist es. Die Task sind alle rot. Im Meldungsfenster werden alle Aktionen ganz langsam abgearbeitet. (Aktionen die in einer Sekunde ablaufen müssten brauchen ca 5 sec.) Das System reagiert dann verzögert( Im Moment ca 20min)
Nein - die DB ist nicht korrupt. Ich habe sie bereits getestet.
Hallo Christian,
testen alleine reicht oft nicht aus.
Meine zeigte mir auch keine Fehler, erst nachdem ich die db komplett wiederhergestellt hatte läuft alles zu meiner Zufriedenheit.
Ok,
ich habe die Datenbankwiederherstellung durchlaufen lassen. Leider ohne Erfolg.
Die PHP-Task-Queue ist fast leer aber die paar Einträge sind sofort rot.
Vor 10min habe ich die Reagg. gestartet und schon nach 10min hängt IPS 5min nach.
100% CPU!
15:24 ist die Reaggregation mit 1 Variable fertig geworden:mad:
Das System hat sich wieder erholt.
Das bedeutet bei 131 geloggten Var über 130 Stunden:eek:
Fazit: Ich brauche mehr Power:D
Vielleicht hat jemand einen Rat bevor ich umbaue:)
Hi Christian,
eine Frage: du sagtest, du hättest rote Threads in der PHP-Queue. sind diese nun weg (quasi ohne Fremdeingriff) oder hängen die noch rot in der Queue?
Hi!
sichtlich bin ich zu blöd dafür, bei mir funktioniert das nicht.
Habe die Installation wie beschrieben ausgeführt, aber:
1.) den Teilbaum „CpyDB_Visu“ kann ich nicht finden, so soll der sein?
2.) wenn ich das User-Config V2.3 ausführe kommt ein PHP-Fehler
Parse error: syntax error, unexpected ‚;‘ in [RS DB Analyzer\Config\User-Config V2.3] on line 12
=> aah, hier muss man sichtlich auch noch mal die WebFront-ID einstellen
dann funktioniert das script
Jetzt hab ich das auch im Webfront, aber auch da wirft es nur fehlet, z.B.
<b>Notice</b>
: Undefined index: ContentView in
<b>D:\apps\IP-Symcon\scripts\22997.ips.php</b>
on line
<b>19</b>
…
ok, sichtlich ist das script einige Zeit gelaufen im Hintergrund und hat Unmengen an Fehlern geworfen, etwa „Division by Zero“ usw.
aber jetzt zeigt er mir daten im Webfront an
ok, die Fehlermeldung kommt leider dauernd, Ursache ist dass $Statistik[‚Var_Count_Zaehler‘] 0 ist
Error: Warning: Division by zero
Error in Script D:\apps\IP-Symcon\scripts\18078.ips.php on Line 626
133 in IPSLibrary\app\core\IPSLogger\IPSLogger.inc.php (call IPSLogger_Out)
37 in IPSLibrary\app\core\IPSLogger\IPSLogger_PhpErrorHandler.inc.php (call IPSLogger_Err)
626 in 18078.ips.php (call IPSLogger_PhpErrorHandler)
263 in 18078.ips.php (call DataStringDBStatistikTT)
Weiters kommt auch folgender immer
Error: Warning: Cannot modify header information - headers already sent by (output started at D:\apps\IP-Symcon\webfront\data\graph.php:273)
Error in Script D:\apps\IP-Symcon\webfront\data\graph.php on Line 547
133 in IPSLibrary\app\core\IPSLogger\IPSLogger.inc.php (call IPSLogger_Out)
37 in IPSLibrary\app\core\IPSLogger\IPSLogger_PhpErrorHandler.inc.php (call IPSLogger_Err)
in IPSLogger_PhpErrorHandler
547 in webfront\data\graph.php (call header)
2033 in webfront\data\graph.php (call show)
Hallo RS,
Die Threads sind jetzt - ohne Fremdeingriff - nicht mehr rot. Wenn die Bearbeitung der DB nicht zu lange dauert (mehrere Stunden bis Tage - also nur 1 Datensatz) dann erholt sich IPS wieder. Neulich hatte ich die komplette reagg. gestartet da musste ich IPS neu starten und den Timer beenden sonst hätte es mehrere Tage gedauert.
hört sich wirklich „nur“ nach einem Performance-Problem an. Die Threads würden sonst sterben und als rote Leichen in der Queue hängenbleiben. Dann hilft nur IPS-Restart.
Die positive Message: deine DB scheint ok.
Ich bin grad dabei, einen Scheduler für die Reaggregation zu bauen, dann lässt sich die Last evtl. besser über den Tag verteilen.
