Dsmr-reader: Database groeit gestaag
Ik snap de melding, maar kan in de instellingen nergens vinden om dit aan te passen.
Any tips?
zuidwijk
All 12 comments
onder Configuratie -> Retentieconfiguratie wijzigen ?
Helloitsme
on 26 Oct 2020
Dat heb ik dus aangezet (stond uit). Het is van dit:
Naar dit gegaan:
Dit staat nu ingesteld:
zuidwijk
on 26 Oct 2020
@zuidwijk bedankt voor je melding en Helloitsme voor de hulp.
Ik denk dat je het beste even dit issue kunt doorlezen vanaf hier: https://github.com/dennissiemensma/dsmr-reader/issues/1149#issuecomment-708968095
Verder is het aan te raden om de datalogger sleep op minimaal 5 seconden te zetten. Ik kan niet uit je verhaal opmaken wat daar de waarde van is, maar het is meestal de oorzaak van grote datasets. Je kunt op de About-pagina een debuginfo-dump maken om te zien waar dat op staat. Het opschonen van data heeft namelijk weinig effect als er net zo hard weer data bij komt.
Zie verder het gelinkte issue ook voor een vacuumdb na een tijdje opschonen (het geeft weer wat schijfruimte terug). Afhankelijk van je hardware kan het opschonen van je ~22+ miljoen metingen even duren (lees: enkele dagen).
Dus ik kan je aanraden om vooral even 1x per dag die queries van het andere issue uit te voeren voor de voortgang. Het opschonen zal in het begin langzaam gaan en later steeds sneller.
dennissiemensma
on 26 Oct 2020
Mocht het aantal metingen per minuut je trouwens niet zoveel uitmaken, dan kun je de datalogger sleep zelfs op 9 a 10 seconden zetten, voor een nog betere performance/dataopslag. Voor uur/dagverbruik is het namelijk meer dan nauwkeurig genoeg.
Lagere sleeps hebben vooral nut voor het vaker triggeren van bijvoorbeeld eventuele MQTT-koppelingen. Je bent er uiteraard helemaal vrij in.
dennissiemensma
on 26 Oct 2020
@dennissiemensma zal er morgen naar kijken. Hardware en storage is geen issue. Het draait in docker op een i3 / 32GB ram server met voldoende opslag. Is meer dat ik niet van rode meldingen en waarschuwingen hou 馃槃
Alles wat ik kan verbeteren is mooi meegenomen.
M'n sleep proces staat nu op 0,5. Ik log dus elke telegram elke seconde.
zuidwijk
on 26 Oct 2020
Bedankt voor de aanvulling. In jouw geval is het prima om eventueel ruwe data te bewaren, maar als je het zelf ook niet gebruikt zou ik het inderdaad gewoon laten opschonen. Op jouw hardware zal het wel even duren voordat je echt performance issues krijgt, maar een kleinere database is sowieso sneller en ook makkelijker te beheren qua backups.
Mocht de melding niet weg gaan of iets, laat maar weten. De alerts staan in de huidige versie op 1 GB en 20 miljoen metingen.
dennissiemensma
on 27 Oct 2020
Melding mag wat mij betreft inderdaad gesloten worden/blijven.
Wel heb ik nog een klein vraagje naar wat nu de beste instelling is/zijn voor een Raspberry Pi met een SD kaartje.
Om de hoeveel tijd wil je bijvoorbeeld loggen? Neem aan niet elke seconde elke telegram, maar bijvoorbeeld om de 10, 30 of 60 seconde? Ik vraag dit omdat ik heel veel vraag krijg naar een goede logger en in mijn ogen is dat by far jouw dsmr-reader @dennissiemensma. Alleen niet iedereen heeft een server, of wil een server. Een Raspberry Pi is dan een perfecte oplossing, maar wil niet dat de SD kaart binnen enkele maanden al kapot gaat door de hoge writes.
zuidwijk
on 27 Oct 2020
Ik denk zelf dat het heel erg afhangt hoeveel waarde men aan de data hecht en hoe technisch die persoon is. Er zijn ook zat betaalde oplossingen beschikbaar en daar ga ik er vanuit dat de data in ieder geval 'veilig' bewaard wordt. Dat neemt wellicht een deel van de 'stress' uit handen. Want DSMR-reader doet een hoop, maar je bent dan wel zelf verantwoordelijk voor de data. Dat is denk ik de grootste afweging voor toekomstige gebruikers.
Wat betreft de sleeptijd, hoger is beter maar ik heb al door de jaren gezien dat dat niet perse de levensduur van de SD-kaart verbetert. Sterker nog, het kan best zijn dat een hoge data doorvoer + opschoning van data, juist voor extra slijtage zorgt wanneer dezelfde sectoren hergebruikt worden, maar ik heb daar geen concrete tests voor gedaan.聽Ik heb daarnaast SD's gehad die een maand meegingen en andere die jaren goed gingen, het blijft een beetje loterij en als ze stuk gaan komt het je nooit uit en met een beetje pech merk je het ook niet direct.
DSMR-v4-meters, die ik ook heb, doen elke 10 seconden een telegram, dus wellicht is dat een redelijk uitgangspunt.
dennissiemensma
on 27 Oct 2020
Ik zit even te spelen met de vacuumdb enzo, maar ik draai het in een container van/via @xirixiz.
````
$ docker exec -it dsmrdb bash
bash-4.4# su - postgres
5e9396a77d7f:~$ vacuumdb -f -v -d dsmrreader
vacuumdb: could not connect to database dsmrreader: FATAL: role "postgres" does not exist
5e9396a77d7f:~$ exit
bash-4.4# exit
$ docker exec -it dsmr bash
bash-5.0# su - dsmr
su: unknown user dsmr
bash-5.0# pwd
/
bash-5.0# ls
bin dsmr home media opt release.txt run sbin sys usr
dev etc lib mnt proc root run.sh srv tmp var
bash-5.0# cd dsmr/
bash-5.0# ls
CHANGELOG backups dsmr_backend dsmr_frontend dsmr_parser dsmrreader pylama.ini
FUNDING.yml check_python_version.py dsmr_backup dsmr_influxdb dsmr_plugins logs reload.sh
LICENCE deploy.sh dsmr_consumption dsmr_mindergas dsmr_pvoutput manage.py setup.cfg
README.md docs dsmr_datalogger dsmr_mqtt dsmr_stats post-deploy.sh tools
RELEASE dsmr_api dsmr_dropbox dsmr_notification dsmr_weather pre-deploy.sh
bash-5.0# ./manage.py dsmr_debuginfo
<--- COPY OUTPUT AFTER THIS LINE AND PASTE IN YOUR GITHUB ISSUE --->
Python version v3.8.5
Platform Linux (x86_64)
System Linux-4.15.0-121-generic-x86_64-with
DSMR-READER
Version v4.5
Backend sleep 1.0 s
Datalogger sleep 0.5 s
Retention cleans up after 672 h
Telegram parser "4"
Database engine/vendor postgresql
DATA
Telegrams
- total (est.) 2267210
- version (latest reading) "50"
Consumption records
- electricity (est.) 50848
- gas (est.) 20762
ISSUES
Database growing large: 5346 MB, consider data cleanup (if not already enabled) Since 2020-11-01 10:25:12.942419+01:00
POSTGRESQL SIZE OF LARGEST TABLES (> 5 MB)
public.dsmr_datalogger_dsmrreading 5177 MB
public.dsmr_consumption_electricityconsumption 148 MB
public.dsmr_consumption_gasconsumption 7856 kB
<--- COPY OUTPUT UNTIL THIS LINE AND PASTE IN YOUR GITHUB ISSUE --->
bash-5.0#
````
Dit dus:
Python version v3.8.5
Platform Linux (x86_64)
System Linux-4.15.0-121-generic-x86_64-with
DSMR-READER
Version v4.5
Backend sleep 1.0 s
Datalogger sleep 0.5 s
Retention cleans up after 672 h
Telegram parser "4"
Database engine/vendor postgresql
DATA
Telegrams
- total (est.) 2267210
- version (latest reading) "50"
Consumption records
- electricity (est.) 50848
- gas (est.) 20762
ISSUES
Database growing large: 5346 MB, consider data cleanup (if not already enabled) Since 2020-11-01 10:25:12.942419+01:00
POSTGRESQL SIZE OF LARGEST TABLES (> 5 MB)
public.dsmr_datalogger_dsmrreading 5177 MB
public.dsmr_consumption_electricityconsumption 148 MB
public.dsmr_consumption_gasconsumption 7856 kB
Nou zegt de postgres vacuumdb melding dat de role postgres niet bestaat, de database draait onder de naam dsmrreader. Dus geef ik dat als user op:
````
bash-4.4# vacuumdb -f -v -d dsmrreader -U dsmrreader
vacuumdb: vacuuming database "dsmrreader"
INFO: vacuuming "public.dsmr_backend_backendsettings"
INFO: "dsmr_backend_backendsettings": found 0 removable, 1 nonremovable row versions in 1 pages
DETAIL: 0 dead row versions cannot be removed yet.
...
<...veel output...>
...
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO: vacuuming "public.dsmr_mqtt_mqttbrokersettings"
INFO: "dsmr_mqtt_mqttbrokersettings": found 0 removable, 1 nonremovable row versions in 1 pages
DETAIL: 0 dead row versions cannot be removed yet.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
bash-4.4#
bash-4.4# exit
exit
$ docker exec -it dsmr bash
bash-5.0# /dsmr/manage.py dsmr_debuginfo
<--- COPY OUTPUT AFTER THIS LINE AND PASTE IN YOUR GITHUB ISSUE --->
Python version v3.8.5
Platform Linux (x86_64)
System Linux-4.15.0-121-generic-x86_64-with
DSMR-READER
Version v4.5
Backend sleep 1.0 s
Datalogger sleep 0.5 s
Retention cleans up after 672 h
Telegram parser "4"
Database engine/vendor postgresql
DATA
Telegrams
- total (est.) 2250790
- version (latest reading) "50"
Consumption records
- electricity (est.) 50928
- gas (est.) 19533
POSTGRESQL SIZE OF LARGEST TABLES (> 5 MB)
public.dsmr_datalogger_dsmrreading 416 MB
public.dsmr_consumption_electricityconsumption 17 MB
<--- COPY OUTPUT UNTIL THIS LINE AND PASTE IN YOUR GITHUB ISSUE --->
bash-5.0#
````
Veel debug en trial/error... maar zo te zien is het goed opgeschoond (en dat ging binnen enkele secondes :-) )
Python version v3.8.5
Platform Linux (x86_64)
System Linux-4.15.0-121-generic-x86_64-with
DSMR-READER
Version v4.5
Backend sleep 1.0 s
Datalogger sleep 0.5 s
Retention cleans up after 672 h
Telegram parser "4"
Database engine/vendor postgresql
DATA
Telegrams
- total (est.) 2250790
- version (latest reading) "50"
Consumption records
- electricity (est.) 50928
- gas (est.) 19533
POSTGRESQL SIZE OF LARGEST TABLES (> 5 MB)
public.dsmr_datalogger_dsmrreading 416 MB
public.dsmr_consumption_electricityconsumption 17 MB
(vond dit wel een mooie toevoeging om in de toekomst terug naar te refereren :) )
zuidwijk
on 1 Nov 2020
Hmm, misschien is er een oplossing voor die ik kan opnemen. Je kan het ook als volgt uitvoeren:
docker exec -ti <container-name> bash -c 'PGPASSWORD=${DB_PASS} /usr/bin/vacuumdb -f -v -h ${DB_HOST} -d ${DB_NAME} -U ${DB_USER}'
...added to the readme for Docker environments
xirixiz
on 1 Nov 2020
Goedemorgen, ik heb de documentatie aangepast en een nieuwe release uitgebracht zodat er een cleanup script in de docker image zit. De variabele voor DB_PORT is ook opgenomen en daarnaast zit er een check in of de backend een postgresql omgeving betreft.
Opschoning kan nu als volgt gestart worden:
docker exec -ti dsmr bash -c '/app/cleandb.sh'
Of verbose
docker exec -ti dsmr bash -c '/app/cleandb.sh -v'
Related issues
GreyEarl
路
9Comments
dennissiemensma
路
4Comments
swerveshot
路
4Comments
KobeBergmans
路
4Comments
hollie
路
7Comments
Most helpful comment
Goedemorgen, ik heb de documentatie aangepast en een nieuwe release uitgebracht zodat er een cleanup script in de docker image zit. De variabele voor DB_PORT is ook opgenomen en daarnaast zit er een check in of de backend een postgresql omgeving betreft.
Opschoning kan nu als volgt gestart worden:
Of verbose