Closed sjaakveenendaal closed 3 years ago
Bedankt voor je melding. Ik heb wel wat meer informatie van je nodig, waar bij het aanmaken van issues op gehint wordt.
Als de backup groot is dan heb je waarschijnlijk teveel data. Heb je retentie aan staan? En wat is je datalogger sleep? En hoe groot is je database?
sudo su - postgres
psql dsmrreader
SELECT nspname || '.' || relname AS "relation",
pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT IN ('pg_catalog', 'information_schema')
AND C.relkind <> 'i'
AND nspname !~ '^pg_toast'
ORDER BY pg_total_relation_size(C.oid) DESC
LIMIT 20;
Retentie staat op geen Database is 2 gb dropbox datalogger sleep0.5
Als je geen retentie aanzet en tevens een lage sleep (ik mis nog steeds info over je installatie), dan groeit de data vanzelf dusdanig dat je grotere en tragere backups krijgt. Afhankelijk van je hardware wil je daar mogelijk (of niet) een andere keuze in maken.
Dat verklaart niet waarom er 5x op een dag een backup gemaakt wordt. Mogelijk faalt die en probeert die het opnieuw? Heb je genoeg disk ruimte? Heb je ze log al bekeken in debug mode? Zie ook bovenstaande link.
Ter vergelijking, ik gebruik een week retentie, welliswaar met DSMR4-meter, maar na bijna 5 jaar aan gegevens is de database totaal zo'n 200 MB groot. Daardoor zijn mijn full-backups ook slechts 5 MB groot.
Als je geen use-case hebt om alle/veel data op te slaan kan ik je dat ook van harte aanraden. Dat maakt je hele installatie en dataopslag kleiner, sneller en het bespaart je ook aardig wat performance issues op de lange duur. Maar dat is uiteraard helemaal aan jezelf.
ik heb de retentie ook op een week gezet kijken wat het doet
maar ging de hele tijd goed en na de laatste update in eens updates van meer dan 300 mb
Bedankt voor je aanvulling. Wellicht dat dit onbewust al een tijdje speelde, want updates zorgen doorgaans niet zomaar voor extra data. Daarnaast kan ik je aanraden om de datalogger sleep wat op te hogen als je zelf niet elke seconde data hoeft te meten en opslaan. Dat scheelt aanzienlijk in de dataopslag en -grootte.
Het staat je verder uiteraard vrij om terug te gaan naar en te blijven op een DSMR-reader versie die naar wens werkte. Updaten is een aanbeveling, maar geen must.
Als je trouwens wilt zien in hoeverre retentie je data opruimt (dit kan even duren), zie vooral de info uit deze thread: #1071
@sjaakveenendaal is het issue inmiddels opgelost met minder data?
Nee sorry
Zou je dan eens willen upgraden naar de laatste versie en dan de output van dit willen delen: https://dsmr-reader.readthedocs.io/en/latest/troubleshooting.html#debug-info-dump-for-github-issues
Dank je voor de reactie
Ik draai altijd de laatste versie
<--- COPY OUTPUT AFTER THIS LINE --->
DSMR-READER
Version v4.4.1
Database engine/vendor postgresql
Setting: Backend process sleep 1.0 s
Setting: Datalogger process sleep 1.0 s
Setting: Retention cleans up after None h
SMART METER
Telegram version (latest reading) v50
Setting: Telegram parser 4
DATA
Met vriendelijke groet,
Sjaak van Veenendaal
@sjaakveenendaal bedankt voor de update. Ik mis echter een deel van de informatie, juist de datagrootte die interessant is.
Verder zie ik dat retentie uit staat, terwijl je eerder aangaf die op een week te hebben gezet, klopt dat? Als je die niet gebruikt blijft je data groeien en de backups dus ook.
Staat nu op een maand maar wat gebeurt er in het overzicht kan ik dan maar een maand terug kijken of heeft dit geen effect op wat ik te zien krijg in dsmr?
De back-ups zijn per keer rond de 300 mb
Retentie schoont alleen de metingen op. Alle dagtotalen blijven altijd bewaard.
Zou je nog eens de output van dsmr_debuginfo
willen delen, maar dan de volledige dump?
@sjaakveenendaal retentie schoont alleen de metingen op. Alle dagtotalen blijven altijd voor je bewaard. Zou je nog eens de output van dsmr_debuginfo
willen delen, maar dan de volledige output?
sinds een paar dagen maakt dsmr een backup van ruim 360 mb aan en dan wel 5 x op een dag