[vz-users] falschen Messwert in der Aggregation löschen

[Andreas Goetz]

Hi,

2017-02-09 13:23 GMT+01:00 <china2013 at abwesend.de>:

> Hallo Andreas,
>
> also ich komm von unterwegs mit putty drauf. Vermutlich hast du Port 22
> verwendet. Ich hatte geschrieben der Port ist 2222
>

Ok- wer lesen kann :/


>  - in cron sind die Zeilen mit aggregate seit gestern lahmgelegt.
>  - Tabelle ist bereits komplett leer, wurde mit "aggregate clear"
> erfolgreich gelöscht.
>  - trotzdem steigt "aggrgate day mit einer einzigen UUID" nach spätestens
> 15 minuten mit Error aus.
>
> Re: Häh? Womit kommt das nicht zurecht?
> ok, ein "aggrgate day mit dem Channel Auto" funktioniert, weil da kaum
> Daten drin sind.
> Die anderen Channels haben bestimmt 100.000-fach mehr Daten und damit
> macht aggrgate immer Error (wenn die Tabelle leer ist)
>

Der Fehler den Du angegeben hast lautet... General error: 126 Incorrect key
file for table '/tmp/#sql_423_1.MYI'; try to repair it

Also ggf. kaputte Datenbank. Müssen wir neu testen wenn die Tabelle mal
platt gemacht ist.


>
> Re: Du hast dabei die DB zerschossen...
> Na ich hoffe nicht, denn aggrgate day mit dem Channel Auto funktioniert ja
> noch oder es liegt daran, dass dieser Channelvom Typ "S0-Impulse" ist.
>

Also ich weiss nicht an welcher Stelle die Tabelle kaputt ist- da ist alles
möglich. Ich hab die Tabelle jetzt gekillt und neu erzeugt, derzeit läuft
aggregate.

Prinzipiell halte ich das Setup für Mist- in my.cnf steht /tmp als temp
Ordner, das ist bei Dir ein 30MB Block. Auf dem rödelt jetzt eine 3,5GB
Datenbank rum. DAS MUSS FRÜHER ODER SPÄTER CRASHEN!!!

Immer wieder werde ich gefragt warum die 2-Sekundenaufzeichnung: Weil ich
> nur so an vernünftige Gradientenwerte herankomme. Minuten sind eine ganze
> Größenordnung zu langsam.
> Also, Das Systen ist noch online - habs gerade gestetet und aggregate ist
> aktuell leer (truncate)
>

Neuaufbau aggregate läuft. Wenn das wieder crasht muss der /tmp Ordner
geändert werden.


> Viele Grüße
> Saftwerk
>

vg
Andreas


>
> *Gesendet:* Donnerstag, 09. Februar 2017 um 09:11 Uhr
> *Von:* "Andreas Goetz" <cpuidle at gmail.com>
> *An:* "volkszaehler.org - users" <volkszaehler-users at demo.volkszaehler.org
> >
> *Betreff:* Re: [vz-users] falschen Messwert in der Aggregation löschen
> Moin
>
> > On 9 Feb 2017, at 01:41, china2013 at abwesend.de wrote:
> >
> >
> >> Und mal interessehalber: wie groß ist deine DB mittlerweile, wenn du
> keinerlei vzlogger-Aggregation benutzt?
> > sudo ls -l /var/lib/mysql/ = 3693 MByte ibdata1
> >
> >> Archivierst du alles oder dünnst du später aus?
> > Alles! Erst wenn 365 Tage komplett sind gibts eine neue Datenbank
> > Aber ich hab so meine Zweifel, dass das klappt. Man muss zu oft Hand
> anlegen.
> > Meine beiden PV-Überwachungen laufen seit 5 Jahren noch mit der ersten
> Speicherkarte ohne Probleme.
>
> Warum auch immer Du für pv Sekundenwerte brauchst.
>
> > ...
> >
> >> Hab das nachgeprüft: laut entities.js verwendet das Frontend nur
> group=day und group=hour. Wenn du minute auch nicht manuell verwendest,
> bringt es keinen Vorteil.
> > Danke, also noch ein Grund das aggregate.php zu überarbeiten und
> "Minute" entsorgen.
>
> Mit aggregate ist alles in Ordnung- benutz es halt einfach nicht mit
> Minuten!
>
> > Letztlich war aggregate.php der Grund des ganzen Übels, dass es mit
> großen Datenmengen nicht zurechtkommt.
>
> Häh? Womit kommt das nicht zurecht?
>
> > Es war ja leider nur ein gut gemeinter Rat, der aufgedeckt hat, dass
> aggregate nun gar nicht mehr will.
>
> Irgendwie gefällt mir der Ton nicht.
>
> Deinen originären Fehler haben wir nie diagnostiziert weil Du bis heute
> die Rohdaten nicht gepostet hast. Stattdessen kam die Holzhammermethode zum
> Einsatz.
>
> Ich würde sagen Du hast dabei die DB zerschossen indem Du gleichzeitig
> versucht hast a) alles aus aggregate zu löschen und b) die Tabelle je
> Minute komplett wieder neu aufzubauen. Irgendwann gabs out of memory und
> Korruption.
>
> Anwenderfehler!
>
> Jetzt gilt es:
>
> - tabelle mittels drop entsorgen
> - tabelle mittels misc/tools/doctrine orm:schema-tool:update neu aufbauen
> - währenddessen crontab lahm lagen
> - aggregate von hand mittels misc/tools/aggregate neu aufbauen
> - crontab ohne Minuten wieder in Betrieb nehmen
> - und dann abwarten
>
> >
> > Viele Grüße
> > Saftwerk
>
> Viele Grüße, Andreas
>
> PS.: fixen kann ich nix weil ssh nicht antwortet...
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20170209/ecc738b5/attachment.html>