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

Andreas Goetz cpuidle at gmail.com
Thu Feb 9 14:14:10 CET 2017


2017-02-09 13:51 GMT+01:00 Andreas Goetz <cpuidle at gmail.com>:

> Hi,
>
> 2017-02-09 13:23 GMT+01:00 <china2013 at abwesend.de>:
>
>> Hallo Andreas,
>> ...
>>
>>
>
>> 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.
>

... und es crasht wieder. Ordner auf /var/tmp verbogen- jetzt stehen da
beim Lauf über Tage mit delta schonmal Tempdateien mit ca. 300MB drin.

Long story short: /tmp ist der falsche Ordner für mysql wenn größere
Datenmengen bewegt 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.volks
>> zaehler.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/43730958/attachment.html>


More information about the volkszaehler-users mailing list