AvrLogger : Thermallogger und Visualisierung Tool

BigRonin

Benutzer
Mitglied seit
08. Mai 2015
Beiträge
1.156
Punkte für Reaktionen
131
Punkte
89

faxxe

Benutzer
Mitglied seit
22. Nov 2007
Beiträge
228
Punkte für Reaktionen
56
Punkte
34
Vielen Dank...das war die Lösung

-faxxe
 

vater

Benutzer
Contributor
Mitglied seit
14. Mrz 2014
Beiträge
487
Punkte für Reaktionen
107
Punkte
43
Hallo BigRonin,

vielen Dank für das Paket. Ich habe gestern das 009 installiert und heute auf 010 aktualisiert.

Ein bisschen verwundert mich der Anstieg um ca. 13:00 Uhr, dem Zeitpunkt meines Updates auf 010.
AvrLogger_nachInstallation.jpg


Viele Grüße und nochmals vielen Dank! :)
Vater
 

BigRonin

Benutzer
Mitglied seit
08. Mai 2015
Beiträge
1.156
Punkte für Reaktionen
131
Punkte
89
Ist die Auslastung immer noch so ungewöhnlich hoch?

Schau doch bitte mal im Ressourcen-Monitor unter Aufgaben-Manager und Prozesse nach „AvrLogger.sh“ und „index.cgi“ … „wenn“ die vorhanden sind, dann höchstens jeweils 1x und die Auslastung, je nach DS, zwischen 0 und 0,5%.

Ich würde gerne mal versuchen das zu reproduzieren … hattest du das Fenster von AvrLogger während des Updates offen? Wenn ich fragen darf, auf welcher DS installiert und wie viele HDD’s?
 

peterhoffmann

Benutzer
Sehr erfahren
Mitglied seit
17. Dez 2014
Beiträge
6.057
Punkte für Reaktionen
1.855
Punkte
254
Mir ist die gefühlt recht hohe Auslastung von Anfang an aufgefallen.

Auf der Konsole unter "top" habe ich für die
Rich (BBCode):
/bin/bash /volume1/@appstore/AvrLogger/AvrLogger.sh
meist 2%, oft 3.3% bis 4%, ab und zu 1,3%.
"top" läuft bei mir mit sekündlichem Refresh.
 

blurrrr

Benutzer
Sehr erfahren
Mitglied seit
23. Jan 2012
Beiträge
6.204
Punkte für Reaktionen
1.104
Punkte
248
@DKeppi, das ist sogar noch relativ günstig :eek:
 

BigRonin

Benutzer
Mitglied seit
08. Mai 2015
Beiträge
1.156
Punkte für Reaktionen
131
Punkte
89
Das ist „zumindest“ zurzeit normal.

Die „AvrLogger.sh“ ist der Daemon der regelmäßig die Werte ermittelt und in eine Datei schreibt. Je nach Einstellung in „Timeline“ werden die Werte in unterschiedlichen Abständen ermittelt.

Timeline / Zeit in Sekunden:
1h = 1 sek.
2h = 2 sek.
3h = 3 sek.
6h = 3 sek.
12h = 3 sek.
24h = 6 sek.
48h = 6 sek.
128h = 6 sek.

Das bedeutet, je kleiner Timeline, je höher ist der Load. Das fällt natürlich umso deutlicher auf, wenn die DS nicht so „potent“ ist. Wenn der Bedarf da ist, baue ich gerne eine Funktion ein die es Erlaubt, die Abfragehäufigkeit weiter zu senken. Das geht natürlich zu Lasten der Genauigkeit. Kurzzeitige „Spitzen“ werden dann nicht mehr erfasst.

Wie gesagt … sowas baue ich gerne ein :)
 

peterhoffmann

Benutzer
Sehr erfahren
Mitglied seit
17. Dez 2014
Beiträge
6.057
Punkte für Reaktionen
1.855
Punkte
254
Die Abstände empfinde ich als sehr kurz. Da es bis auf Load nur um die Temperaturen geht, hätte ich da eher auf 20s bis 30s getippt.

Eine Einstellmöglichkeit würde ich mir da wünschen.

Nachtrag:
Ich habe es gerade mit 1 Stunde und 168 Stunden getestet. Wirklich einen Unterschied sehe ich unter top aber nicht.
 

BigRonin

Benutzer
Mitglied seit
08. Mai 2015
Beiträge
1.156
Punkte für Reaktionen
131
Punkte
89
Ok :) Werde ich einbauen.

Mir schwebt da was vor wie: Genauigkeit (Accuracy) in "high" / "middle" / "low"
"high" würde dem aktuellen Zustand entsprechen.

Die Routinen in AvrLogger haben bereits umfangreiche Parametriermöglichkeiten so dass ich eventuell noch heute eine „Test-Version“ bereitstellen kann.
 

peterhoffmann

Benutzer
Sehr erfahren
Mitglied seit
17. Dez 2014
Beiträge
6.057
Punkte für Reaktionen
1.855
Punkte
254
Hört sich gut an.

Ich habe es jetzt mal über ein paar Minuten in top beobachtet. Bei 168 Stunden sind es meist 2%, bei 1 Stunde geht die Tendenz mehr zu 3%. Der Unterschied ist somit leider recht gering.
Wieso verursacht überhaupt der Daemon durchgehend eine Last, wenn er doch bei 6s Abständen (168 Stunden) mindestens 5s nichts zu tun hat?
 

vater

Benutzer
Contributor
Mitglied seit
14. Mrz 2014
Beiträge
487
Punkte für Reaktionen
107
Punkte
43
Es läuft bei mir auf der RS2414+, die alle 12 Slots belegt hat.
Mh. Ich glaube das Fenster war zum Zeitpunkt des Updates geschlossen.
AvrLogger.sh liegt bei 0,4% CPU Auslastung, bei geöffnetem Fenster 0,6%.
index.cgi schläft
Um 16 Uhr hat sich alles (natürlich bis auf HDD average) wieder relativiert. Komisch. Doch nicht so komisch, es liefen zu der Zeit einige Backups. Vermutlichen haben die sich in dem Anstieg geäußert. Ich beobachte das mal weiter.

AvrLogger_01.jpg
 

BigRonin

Benutzer
Mitglied seit
08. Mai 2015
Beiträge
1.156
Punkte für Reaktionen
131
Punkte
89
Es ist nicht so dass zwischen den Werteauslesen nichts zu tun ist, in der „Wartezeit“ wird alle 250ms geprüft ob die Einstellungen geändert wurden (baue ich gerade um), es wird geprüft ob die Grafik „archiviert“ werden soll. Dann wir ein Zähler geprüft ob die Werte aus dem „moving average filter“ geschrieben werden sollen. Alles in allem nicht wirklich viel was da passiert … tatsächlich „schläft“ der Daemon zwischen den Aktionen aktuell immer 250ms. Geplant war demnächst 333ms … aber mit dem Einbau der neuen Funktion werde ich die „Schlafzeit“ an die Abfragehäufigkeit anpassen und so die Gesamtlast weiter senken.

Ich bin ständig am optimieren :) und da geht noch was … Manche Ideen und Wünsche dazu kommen jetzt erst durch solche Feedbacks.

Also … ich bin am Ball
 

BigRonin

Benutzer
Mitglied seit
08. Mai 2015
Beiträge
1.156
Punkte für Reaktionen
131
Punkte
89
so ...

Eine TEST-Version liegt auf meinem Server

Die neuen Abfrageintervalle im einzelnem:

Rich (BBCode):
      high - middle - low - yawn
------------------------------------------
  1h =   1     3       5      6
  2h =   2     3       8     12
  3h =   3     5      10     15
  6h =   3     5      10     30
 12h =   3     8      10     40
 24h =   6    10      15     60
 48h =   6    20      30    120
168h =   6    30      40    240

Auch habe ich Erkennung ob Einstellungen geändert wurden umgestellt. Ich sende nun aktive Signale zwischen dem Daemon und dem Fenster.
In ersten Tests funktioniert es. Mit einer Einschränkung: Wird das Fenster von AvrLogger komplet verdeckt, funktioniert die Aktualisierung der Grafik nicht mehr.
Ich muss noch weiter schauen wie ich das wieder hinbekomme.

Aber soweit müsste AvrLogger dennoch funktionieren.
 

peterhoffmann

Benutzer
Sehr erfahren
Mitglied seit
17. Dez 2014
Beiträge
6.057
Punkte für Reaktionen
1.855
Punkte
254
Ich habe die Testversion installiert.

Bei mir stand und steht die Timeline auf 168 Stunden. Nach der Installation der Testversion habe ich bei Accuracy auf "middle" gestellt.
Weitere Änderungen habe ich nicht vorgenommen.

Ergebnis war, dass vorher der Load zwischen 5 und 7% lag, mit der Testversion nur noch bei 2%.
testversion.jpg

Bestätigt wird das auch, wenn man "top" beobachtet. AvrLogger.sh liegt da recht stabil bei 0,7%, manchmal 1,3%.
 

BigRonin

Benutzer
Mitglied seit
08. Mai 2015
Beiträge
1.156
Punkte für Reaktionen
131
Punkte
89
Das ist ja schon mal ein Anfang :) .... das scaliert mit meinen Messungen mit top auf der DS2415+.

Traust du dir zu mit WinSCP einen Parameter zu ändern? Für einen kleinen weitern Test?
 

peterhoffmann

Benutzer
Sehr erfahren
Mitglied seit
17. Dez 2014
Beiträge
6.057
Punkte für Reaktionen
1.855
Punkte
254

BigRonin

Benutzer
Mitglied seit
08. Mai 2015
Beiträge
1.156
Punkte für Reaktionen
131
Punkte
89
haha ... hm :p

in der Datei: /var/packages/AvrLogger/target/lib/init.sh stehen ab Zeile 162 für "middle" die Timer- / Filterwerte und noch ein paar andere.
Der Parameter SleepTick="0.500" bestimmt wie oft ich andere Ereignisse prüfe. Denn kannst du ändern. Bei einem zu großem Wert reagiert AvrLogger aber entsprechend "langsamer" auf Änderungen in den Einstellungen.

Wenn du ab Zeile 188 schaust, da steht ein Wert von SleepTick="1.000" das war gefühlt noch akzeptabel.

Wenn du nach dem Ändern einfach einmal auf "Save" in Avr-Config klickst, werden die Werte ausgelesen bzw. übernommen.

Ups ... stimmt ja garnicht ... du musst AvrLogger neustarten.
 
Zuletzt bearbeitet:

peterhoffmann

Benutzer
Sehr erfahren
Mitglied seit
17. Dez 2014
Beiträge
6.057
Punkte für Reaktionen
1.855
Punkte
254
So, ich habe nun insgesamt drei verschiedene Werte für SleepTick durchprobiert und jeweils immer ein paar Stunden laufen lassen.

Standardinstallation Testversion 11, hier aus dem Thread.
Frische Installation ohne (alte) Daten, Werte alle Standard, Bereich 24 Stunden.


Rich (BBCode):
SleepTick: Vorgabe (verschiedene Werte)
high   = 3,3 %
middle = 2,4 %
low    = 2,2 %
yawn   = 1,7 %

SleepTick: 2.000 (überall)
high   = 2,2 %
middle = 1,3 %
low    = 1,2 %
yawn   = (ausgelassen)

SleepTick: 5.000 (überall)
high   = 1,3 %
middle = 1,2 %
low    = (ausgelassen)
yawn   = (ausgelassen)

Werte sind locker +-0,2%, da ich optisch nach dem Plot ausgewertet habe.
"(ausgelassen)" habe ich die Werte dann, wenn ersichtlich war, dass keine Verbesserung mehr sichtbar oder zu erwarten war.

Mit einer schwächeren DS (z.B. DS115j oder DS215j) hätte man das besser testen können, da die Differenzen besser sichtbar gewesen wären.
 

BigRonin

Benutzer
Mitglied seit
08. Mai 2015
Beiträge
1.156
Punkte für Reaktionen
131
Punkte
89
Erstmal ein herzliches Dankeschön für die Arbeit die du dir erneut gemacht hast!

Deine Ergebnisse zeigen deutlich, dass es richtig war, die „Accuracy“-Profile einzuführen.

Ich war inzwischen nicht untätig und habe alle regelmäßig aufgerufene Ereignisse, die ich im Daemon „gepollet“ hatte, umgestellt auf einen „Cron-Job“. Die zeitliche Aktualisierung des Plot’s und die Archivierung, werden nun in der „crontab“ eingetragen und ausgeführt. Ein „pollen“ entfällt nun komplett. Der Daemon prüft zwischen den Abfragen neuer Sensor-Daten nur noch, ob es an der Zeit ist, neue Werte zu ermitteln. Deine ermittelten „SleepTick“-Werte habe ich in deiner Größenordnung nicht übernehmen können. Der Grund ist, dass sich der Cron-Job, die GUI und der Daemon bei zu großen Werten verhaspeln. Das Gleiche ist im start-stop-status Script passiert. Ich glaube aber, dass mit den „Accuracy“-Profilen und die Umstellung auf „Cron-Job“, eine gute Balance gefunden ist. Die „Accuracy“-Profile „low“ und „yawn“ hab ich noch einmal angepasst so dass für die Plots „weniger“ Werte benutzt und verarbeitet werden müssen.

Zur Zeit teste ich noch die neue Version … wenn ich mir zu 100% sicher bin, dass ich die Handhabung der Cron-Jobs; das Eintragen; Löschen und Ändern der Timings (Einträge) in der „crontab“ fehlerfrei mache, kommt das Update.

Bei Interesse, lege ich die neu Version vorab, gerne als „TEST“-Version nochmal auf meinen Server.

Einen Nebeneffekt gibt es mit den Umstellungen jedoch. Ich denke, dass ich mich immer weiter davon entferne, den Ruhezustand der DS nicht mehr zu verhindern. Da ist, bis alles Funktioniert, noch viel Gripps und Arbeit reinzustecken „wenn“ ich ein Konzept habe was vielversprechend ist.
 

peterhoffmann

Benutzer
Sehr erfahren
Mitglied seit
17. Dez 2014
Beiträge
6.057
Punkte für Reaktionen
1.855
Punkte
254
Ich stelle mir die Frage, was man überhaupt erreichen will und ob der momentane Stand auf diesem Weg liegt. Manchmal ist es ja so, dass man im Eifer des Gefechts mit solchen Projekten damit über das Ziel hinausschießt, weil man z.B. versucht es so komfortabel wie möglich, für alle Seiten passend und jede noch so erdenkliche Funktion unterbringen will.
Ich habe keine Ahnung, ob das hier der Fall ist. Das kannst du als Progger besser sehen und entscheiden.

Meine bescheidene Meinung als Laie sieht folgendermaßen aus:
Ich möchte wissen, wie in der Vergangenheit der Load, sowie die Temperaturen von CPU und HDDs sich bewegten. Wenn möglich, ohne bzw. nur wenig selbst Load zu erzeugen und (zwecks Ruhezustand) ohne dauernd auf die HDDs zu schreiben.
Ich sehe (als Laie!) keine Notwendigkeit, dass diese Werte in sehr kurzen Zeitabständen (1-2 Sekunden) erfasst werden. Was spricht gegen 15s, 30s oder gar 60s? Für die Temperaturen ist das unkritisch, da die sich sowieso nur sehr träge ändern. Und ein hoher Load, der nur kurz anhält, ist am Ende auch uninteressant. Durch größere Abstände würde das Tool selber kaum noch Load produzieren und die Datenbank klein halten.

Kann man die Werte eigentlich nicht flüchtig im Speicher halten und nur alle xx Stunden auf die HDD schreiben? Im Falle eines Stromausfalles verliert man zwar die Daten, aber das sollte wohl dann das geringste Problem sein.

Aber wie oben schon eingangs erwähnt, die Frage ist ja, was man erreichen will. Meine Ziele müssen ja nicht zwingend deine Ziele sein.

Grundsätzlich finde ich AvrLogger super, ich bin nur erstaunt über die Menge von Programmiercode, sowie über die Problemstellungen die hier auftreten. Wenn man mich im Vorfeld gefragt hätte, ob das schwierig sei, hätte ich verneint. Die Daten selber lassen sich ja jeweils mit einem Einzeiler abfragen. Noch drei Zeilen dazu und fertig ist die Laube. ;)
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat