Dsmr-reader: v3.3.0 100% CPU Load?

[cyberjunky]

Hebben jullie ook last van 100% cpu verbruik door laatste versie?

root     25668 99.0  0.8  71108 67996 ?        RN   22:40   3:36 python3 -u /dsmr/manage.py dsmr_datalogger
root     25665 92.8  0.2  23240 21012 ?        S    22:40   3:48 /usr/bin/python3 /usr/bin/supervisord -n

Gaat er iets fout, maar weet je niet wat? Bekijk de logfiles als startpunt.

Wat gebruik je?

• DSMR-reader versie (rechtsbovenin applicatie zichtbaar): v2.xxx
• Hardware (RaspberryPi 3, 4 of iets anders): RaspberryPi ...
• DSMR-protocol slimme meter (v4 of v5): v...

Beschrijf hier je verhaal...

[dennissiemensma]

Bedankt voor je melding. Het is hiervoor erg handig om te weten:

• welke hardware je gebruikt?
• of je een directe installatie of Docker gebruikt?
• of je een v4 of v5 slimme meter hebt?

[nvdweem]

Bij mij speelt hetzelfde, 2 cores die constant naar 100% gaan:

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
22bb1b6b8df3        dsmr                199.84%             293.3MiB / 31.29GiB   0.92%               5.21MB / 8.32MB     71.3MB / 0B         16

Hardware:

• Unraid op een i7-4770k, 32gb (deze heeft 2 cores op 100%)
• DSMR pakketten worden vanuit een RPi gepost naar /api/v1/datalogger/dsmrreading (hier geen probleem)

Installatie:

• DSMR via Docker: xirixiz/dsmr-reader-docker, latest, 2 dagen geleden

Kaifa MA105, na even googlen is dit een "DSMR 4.0.5 / DSMR 4.0.7" meter.

[cyberjunky]

Ik gebruik geen hardware, ik post via API mijn readings (van een Toon)
Is dat het probleem wellicht, moet/kan ik dat hardware uitlees process disablen?

[cyberjunky]

Ik gebruik docker.

[nvdweem]

Het niet starten van de datalogger lijkt het op te lossen.

@cyberjunky Als je dezelfde docker image gebruikt dan is dat een environment variabele toevoegen zoals beschreven op https://github.com/xirixiz/dsmr-reader-docker:
SD_AUTOSTART_DATALOGGER=false

[cyberjunky]

@nvdweem ja correct, zojuist aangepast.
Dus de logger raakt in een loop als er geen device (of ander serieel) device reageert?

[dennissiemensma]

Bedankt voor het delen van jullie bevindingen! In dat geval laat ik het voor wat het is. De ingebouwde datalogger hoort inderdaad niet te draaien als je hem niet nodig hebt.

[jorkzijlstra]

Is er misschien een mogelijkheid om wanneer dit gebeurd er een health endpoint een status 500 te laten teruggeven? Ik zag op de status pagina geen losse xhr calls gebeuren en de status pagina heeft dus alleen een status 200.

Wanneer er een health endpoint is die status 200 of 500 teruggeeft dan kan je er een alert op maken / de supervisor kan het process herstarten wat dit probleem bij mij altijd lijkt op te lossen. Uiteraard met een backoff strategie anders is er een oneindige restart loop wat ook een hoge cpu tot resultaat heeft.

[jorkzijlstra]

Het gebeurd gelukkig niet veel maar zou toch handig zijn als het automagisch herstarten het oplost.

@cyberjunky Je kan ook een pushnotificatie instellen (bijv Pushover) waardoor je een melding krijgt wanneer er te laten geen berichten zijn binnengekomen. Hierdoor merk je in ieder geval sneller dat het niet werkt.

[dennissiemensma]

Is er misschien een mogelijkheid om wanneer dit gebeurd er een health endpoint een status 500 te laten teruggeven? Ik zag op de status pagina geen losse xhr calls gebeuren en de status pagina heeft dus alleen een status 200.

Wanneer er een health endpoint is die status 200 of 500 teruggeeft dan kan je er een alert op maken / de supervisor kan het process herstarten wat dit probleem bij mij altijd lijkt op te lossen. Uiteraard met een backoff strategie anders is er een oneindige restart loop wat ook een hoge cpu tot resultaat heeft.

@jorkzijlstra hoe bedoel je dat? Krijg je nu dan willekeurig 100% CPU usage op de datalogger en na een herstart is dat weer weg?

[jorkzijlstra]

Ik krijg idd willekeurig (heb nog geen oorzaak gevonden) last van

ERROR:commands:
Traceback (most recent call last):
  File "/dsmr/dsmr_datalogger/services.py", line 77, in read_and_process_telegram
    telegram = next(telegram_generator)
StopIteration
[2020-02-19 19:41:23,128] ERROR    
Traceback (most recent call last):
  File "/dsmr/dsmr_datalogger/services.py", line 77, in read_and_process_telegram
    telegram = next(telegram_generator)
StopIteration

daarna gaat de cpu naar hoge load en bij een herstart is dit dan weer weg.

[dennissiemensma]

Bedankt voor de foutmelding, ik zie nu waar het misgaat!

Het is een foutafhandeling die mist wanneer de verbinding wegvalt (of iets anders fout gaat). De ingebouwde datalogger negeert die situatie onbedoeld, terwijl die gewoon moet crashen, zodat Supervisor hem weer herstart (en opnieuw verbinding maakt).

Ik neem het mee voor de volgende release. Staat voor morgen gepland als ik zelf geen issues erin vind.

[dennissiemensma]

Uitgebracht in v3.4

[jorkzijlstra]

Bedankt, ga het testen zodra de docker image uit is.

[PeterEIER]

Ik draai v3.4 in een docker container en de app is vreselijk traag, CPU 200%... dit zie ik in de log.

Nb. Ik gebruik MQTT niet...

2020-02-22 21:46:31,229 INFO success: dsmr_mqtt entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2020-02-22 21:48:49,845 INFO exited: dsmr_mqtt (exit status 1; not expected)

2020-02-22 21:48:50,889 INFO spawned: 'dsmr_mqtt' with pid 21591

2020-02-22 21:48:52,298 INFO success: dsmr_mqtt entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2020-02-22 21:51:36,131 INFO exited: dsmr_mqtt (exit status 1; not expected)

2020-02-22 21:51:36,534 INFO spawned: 'dsmr_mqtt' with pid 21598

2020-02-22 21:51:37,698 INFO success: dsmr_mqtt entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2020-02-22 21:53:56,493 INFO exited: dsmr_mqtt (exit status 1; not expected)

2020-02-22 21:53:57,529 INFO spawned: 'dsmr_mqtt' with pid 21605

2020-02-22 21:53:58,544 INFO success: dsmr_mqtt entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

[jorkzijlstra]

@PeterEIER Hier had ik ook last van en heb mqtt volledig uitgezet wat jij ook kan gezien je het toch niet gebruikt.

Als je docker gebruikt dan kan dat via:

    - SD_AUTOSTART_MQTT=false
    - SD_AUTORESTART_MQTT=false 

Als je het native draait moet je even in de docs kijken hoe dat kan.

[PeterEIER]

@jorkzijlstra bedankt voor de tip!! Ik heb de 2 statements toegevoegd en de DSMR container opnieuw deployed helaas blijft MQTT crashen en herstarten, ik gebruik de docker container van ualex73. Kortom ik moet nu gaan puzzelen waarom deze commando's bij mij MQTT niet uitzet.

[jorkzijlstra]

@PeterEIER De documentatie van die docker image lijkt geen optie te noemen om de MQTT uit te zetten.

Ik gebruik zelf de image van xiriz die dit wel ondersteunt: https://github.com/xirixiz/dsmr-reader-docker

[PeterEIER]

container van Alex in de ban gedaan en die van Bram geïnstalleerd, CPU load gemiddeld rond 8% met uitschieters naar 25%, DSMRreader werkt weer als van ouds. Bedankt voor de hulp!