[vz-users] Network Error Gateway Timeout

[Tilman Glötzner]

Hallo nochmal

a) Mir ist noch eingefallen, dass es beim Start RPI Unregelmäßigkeiten 
gab und volkszaehler nicht starten wollte. Ich habe ihn mehrfach von 
Hand starten müssen, bis er lief. Die Fehlermeldungen waren:

[Nov 28 01:50:56][main] log level is 3
[Nov 28 01:50:56][s0]   failed to set policy to SCHED_FIFO for 
counter_thread
[Nov 28 01:50:56][s0]   failed to set policy to SCHED_FIFO for 
counter_thread
[Nov 28 01:50:56][s0]   failed to set policy to SCHED_FIFO for 
counter_thread
[Nov 28 01:50:56][]     Startup failed: open direction failed

Ausserdem musste ich auch die middleware von Hand starten. Die lief dann 
aber mit dem ersten Versuch.

b) Ausserdem habe ich ein paar Warnungen von SQL in 
/var/log/mysql/error.log gefunden

2023-12-03  4:04:52 2490 [Warning] Aborted connection 2490 to db: 
'volkszaehler' user: 'vz' host: 'localhost' (Got an error reading 
communication packets)
2023-12-03 11:42:34 2578 [Warning] Aborted connection 2578 to db: 
'volkszaehler' user: 'vz' host: 'localhost' (Got an error writing 
communication packets)
2023-12-03 11:42:58 2588 [Warning] Aborted connection 2588 to db: 
'volkszaehler' user: 'vz' host: 'localhost' (Got an error writing 
communication packets)
2023-12-03 11:43:00 2562 [Warning] Aborted connection 2562 to db: 
'volkszaehler' user: 'vz' host: 'localhost' (Got an error writing 
communication packets)

c) Wäre es möglich, dass z.B. der Index von data beim Starten korrupt 
geworden ist und es deshalb zu den Performance-Problemen kommt? Kann man 
den Index einer Tabelle regenerieren oder zumindest überprüfen?

Danke und Gruß

Tilman

On 01.12.23 11:18, Tilman Glötzner wrote:
> Hallo
>
> ich verwende volkszaehler mit einem  Raspberry Pi Model B Rev 2 mit 
> 512 MB RAM. Nach einem Neustart am 28.11. erhalte ich mit der 
> Einstellung Current praktisch immer einen Timeout-Fehler. Wenn ich die 
> Anzahl der Signale auf 1 reduziere und einen Zeitbereich von circa 1/2 
> Tag auswähle geht es zumeist. Auch das Betrachten von Daten über einen 
> Monate mit der Auflösung 1 Tag bzw 1 Jahr mit der Auflösung 1 Tag 
> funktioniert. Desweiteren fällt auf, die Spalte mit den Zählerständen 
> nicht mehr gezeigt wird.
>
> Hier ein Ausschnitt aus dem Log während eines Prozess, der im Timeout 
> endet:
>
> ec  1 10:39:05 logger systemd[1]: Starting Clean php session files...
> Dec  1 10:39:08 logger systemd[1]: phpsessionclean.service: Succeeded.
> Dec  1 10:39:08 logger systemd[1]: Started Clean php session files.
> Dec  1 10:40:01 logger CRON[13678]: (root) CMD (flock -n 
> /tmp/flock-vz_aggregate.lock php 
> /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute 
> >/dev/null)
> Dec  1 10:50:01 logger CRON[14171]: (root) CMD (flock -n 
> /tmp/flock-vz_aggregate.lock php 
> /var/www/volkszaehler.org/bin/aggregate run -m delta -l minute 
> >/dev/null)
> Dec  1 10:52:54 logger php[3438]: Maximum execution time of 30 seconds 
> exceeded. Closing worker.
> Dec  1 10:52:54 logger php[3438]: Maximum execution time of 30 seconds 
> exceeded. Closing worker.
>
>
> Was noch auffällt, ist der Timestamp des Locks. Den RPI ich für den 
> Einbau einer Erweiterung um 0:35 h (Local Time) am 28.11. herunter 
> gefahren und um 1:53h wieder hochgefahren. Eigentlich war der Rechner 
> zum Zeitpunkt des Timestamps aus. Was mir unklar ist: Muss das Lock 
> nach beenden der aggregate-Scripte wieder gelöscht werden?
>
>  ls -la /tmp/flock-vz_aggregate.lock
> -rw-r--r-- 1 root root 0 Nov 28 01:30 /tmp/flock-vz_aggregate.lock
>
>
> An Sensoren frage ich 3 Zähler mittels S0-GPIO ab, ausserdem 1 
> Smart-Zaehler per IR. Desweiteren einen Solarakku über ein 
> pythonskript und modbus on tcp, und einen Gaszähler mittels python 
> script (holt die Zählerdaten von einen Program lokal über tcp). Die 
> Datenbank lebt auf einer USB-SSD-Festplatte (ASM1051E SATA 6Gb/s bridge)
>
> Die Optimierungen der Datenbank mittels cronjobs habe ich schon vor 
> längerer Zeit implementiert (sieht man auch im Log).
>
> Die Frage ist nun, wo ich Potential habe, die Performance soweit zu 
> verbessern, dass es keine Timeouts mehr gibt. Gleichzeitig würde ich 
> ungerne Daten aus der Datenbank löschen.
>
>
> Danke und Gruß
>
> Tilman
>