Dsmr-reader: Vraag over vacuumdb

[dennissiemensma]

By @neverstoppedaskingwhy

Hoi Dennis,

Sorry voor het hijacken van deze thread, maar ik heb een vraag met betrekking tot

sudo su - postgres
vacuumdb -f -v -d dsmrreader
```

Normaal hoef je dat nooit te doen, maar bij relatief grote database-deletes in korte tijd kan het wat toevoegen.
#1071 (comment)

Ik heb ook sporadisch issues met dsmr op een raspberry pi v3 met de performance of bereikbaarheid van de web interface.

Mijn status voor het uitvoeren van vacuumdb:

  Version                                                    v4.4.3
  Database engine/vendor                                 postgresql
  Setting: Backend process sleep                              1.0 s
  Setting: Datalogger process sleep                           0.5 s
  Setting: Retention cleans up after                          168 h

SMART METER
  Telegram version (latest reading)                             v50
  Setting: Telegram parser                                        4

DATA
  Stored: Telegram records total                             626490
                        \_ unprocessed                          194
  Stored: Electricity consumption records                     36914
  Stored: Gas consumption records                             28838

POSTGRESQL SIZE OF LARGEST TABLES (> 1MB)
  public.dsmr_datalogger_dsmrreading                        5039 MB
  public.dsmr_consumption_electricityconsumption             228 MB
  public.dsmr_consumption_gasconsumption                      11 MB
  public.dsmr_stats_hourstatistics                          1576 kB
  public.dsmr_weather_temperaturereading                    1336 kB

Mijn status na vacuumdb:

  Version                                                    v4.4.3
  Database engine/vendor                                 postgresql
  Setting: Backend process sleep                              1.0 s
  Setting: Datalogger process sleep                           0.5 s
  Setting: Retention cleans up after                          168 h

SMART METER
  Telegram version (latest reading)                             v50
  Setting: Telegram parser                                        4

DATA
  Stored: Telegram records total                             627019
                        \_ unprocessed                           51
  Stored: Electricity consumption records                     36923
  Stored: Gas consumption records                             28840

POSTGRESQL SIZE OF LARGEST TABLES (> 1MB)
  public.dsmr_datalogger_dsmrreading                         120 MB
  public.dsmr_consumption_electricityconsumption              13 MB
  public.dsmr_consumption_gasconsumption                    3000 kB
  public.dsmr_stats_hourstatistics                          1552 kB
  public.dsmr_weather_temperaturereading                    1312 kB

De retention had ik aan het begin van het jaar gereduceerd naar één week. Kan het zijn, dat op deze hardware met deze instellingen het te lang duurt om "overbodige" database entries te verwijderen, zodat een vacuumdb gewoon noodzakelijk is?

Om problemen bij nieuwe installaties te vermeiden, is het misschien een idee om bij telegram formaat versie v50 de retentie via het backend niet langer als één week instelbaar te maken?

Bedankt,
Mark

[dennissiemensma]

@neverstoppedaskingwhy bedankt voor je vraag. In principe zouden nieuwe installaties sowieso al met een datalogger sleep van 5 moeten draaien, waardoor dit niet meer zo'n issue wordt. Het instellen van retentie van een week zou verder ook niet uit hoeven maken.

Uiteindelijk is het namelijk een gevolg van de hoeveelheid data die binnenkomt. Dan is het wellicht praktischer om die aanvoer van data zoveel mogelijk te beperken, voornamelijk bij DSMR-v5 meters.
Als je zelf geen belang hebt bij elke seconde een telegram dan kan ik je aanraden de datalogger sleep te verhogen, want dan wordt er ook minder data opslagen, hoeft er minder opgeschoond te worden en is de performance op relatief trage hardware (Pi's) al stukken beter.

Klopt het dat je de datalogger sleep zelf weer verlaagd hebt? En anders is een automatische migratie in juli wellicht niet bij iedereen even goed gegaan. Ik kan je sterk aanraden om die minstens op 5 seconden te zetten. Vermoedelijk lost dat ook je performance issues op, zodra de retentie alle overbodige metingen (na een week) heeft verwijderd.

Ter vergelijking, met een 'sleep' van 10 seconden (DSMR v4), retentie van een week en na bijna 5 jaar aan data heb ik het zelf zo:

    Telegrams                                                                                 
      - total (est.)                                                                    143537
      - version (latest reading)                                                          "42"
    Consumption records                                                                       
      - electricity (est.)                                                               93354
      - gas (est.)                                                                       41316

POSTGRESQL SIZE OF LARGEST TABLES (> 5 MB)
    public.dsmr_datalogger_dsmrreading                                                   45 MB
    public.dsmr_consumption_electricityconsumption                                       41 MB

Wellicht dat ik in de toekomst de datalogger sleep verplicht op minimaal 5 seconden, omdat het zoveel issues voorkomt. Echter, gezien dat betekent dat ik zelf daarmee de keuze voor alle gebruikers maak, ben ik daar vanzelfsprekend nog wat terughoudend mee.

[dennissiemensma]

Ik zal sowieso standaard de retentie van nieuwe installaties verlagen naar een maand en betere toelichting geven over wat het doet.

[neverstoppedaskingwhy]

Bedankt voor de toelichting. De datalogger sleep heb ik niet opnieuw ingesteld, ik zal het nog even afwachten en dan eventueel aanpassen. Ik gebruik dsmr direkt, niet in docker.

Op zich is het wel fijn om in de webinterface het effect van het in- of uitschakelen van een apparaat meteen te kunnen zien, maar deze seconde waardes hoeven niet perse in de database.

Na de handmatige vacuumdb reageert het systeem in ieder geval wel merkbaar sneller.

[dennissiemensma]

Zojuist uitgebracht in v4.5