Closed svdo closed 4 years ago
Ik weet inmiddels wat het probleem is, alleen nog niet hoe ik het op moet lossen. De id
s die worden gebruikt om in dsmr_datalogger_dsmrreading
te schrijven zijn namelijk verkeerd. Blijkbaar is 'ie weer vooraan begonnen, in plaats van verder te gaan waar 'ie was gebleven met ids.
Bijvoorbeeld deze query geeft twee resultaten:
select * from dsmr_datalogger_dsmrreading where id=1100;
Ik heb besloten om de tabel te repareren door zelf de id's te veranderen zodat ze weer uniek oplopend zijn. Heb ok de public.dsmr_datalogger_dsmrreading_id_seq
sequence goed gezet. Statistiektabellen voor day en hours leeggemaakt en id_seqs teruggezet op 1, zojuist de boel weer gestart. 🤞
Bedankt voor je melding. Begrijp ik het goed dat je het inmiddels zelf hebt kunnen oplossen?
Geen idee eigenlijk. De foutmelding MultipleObjectsReturned
is weg, maar ik zie nog steeds die spinners. De dagelijks en "uurlijkse" statistiektabellen blijven (vooralsnog?) leeg. En als ik bv de statuspagina probeer te openen krijg ik een timeout. Hij lijkt ergens druk mee bezig, maar ik heb geen idee of 'ie het goede aan het doen is.
Het valt me trouwens ook op dat de laatste DsmrReading
s wel in de database staan, maar dat de grafieken van de afgelopen 24 uur in de UI (die verschijnen wel) zo'n 20 uur achter lopen.
Je kunt het beste even in de logs kijken van dsmr_backend
. https://dsmr-reader.readthedocs.io/nl/v2/troubleshooting.html
Ik heb in settings.py
debug logging aangezet en post-deploy.sh
gedraaid en ook met supervisorctl
alles herstart. Ik zie log files in /var/log/supervisor' en in
~dsmr/dsmr-reader/logs. Die laatste lijken niet gebruikt te worden? Die in
/var/log/supervisor` laten nu idd ook de telegrams zien. Verder zie ik:
==> dsmr_backend.log <==
[2019-10-30 07:52:53,322] DEBUG - Processed reading: 12566521 @ 2019-10-27 21:27:47+01:00
Dat lijkt raar, de datum is nu 30 oktober, maar hij verwerkt één telegram van 27 oktober. Als ik /status
op probeer te vragen, krijg ik een timeout maar verder geen enkele extra logging.
Heb je nog ideeën waar ik naar kan kijken?
Als het niet meer te repareren is, is het dan als een soort van "last resort" mogelijk om een nieuwe installatie "from scratch" te doen en daarin alleen alle readings te importeren en dan DSMR Reader alle statistieken opnieuw te laten berekenen of zo? Dat zou ik natuurlijk liever vermijden...
Overigens zitten er nu meer dan 11.6 miljoen rijen in in mijn dsmr_datalogger_dsmrreading
. Ik vraag me af of ik niet gewoon tegen performance problemen aan zit te kijken...
Update:
Ik heb twee indexen aangemaakt:
alter table dsmr_datalogger_dsmrreading add primary key(id);
create index on dsmr_datalogger_dsmrreading (timestamp);
Nu heeft 'ie in een paar uur tijd 64 dagstatistieken en 1536 uurstatistieken aangemaakt, waar 'ie eerder nog geen handvol had gemaakt in een paar dagen tijd. Ik krijg ook weer zinnige grafieken te zien. Ik zal hier updates blijven posten, maar ik denk dat er dus wel een performance probleem is.
Bedankt voor je terugkoppeling. Dat verklaart een hoop. Het is raar dat er indexes missen, ik heb dat 1x eerder gehoord van een gebruiker.
Ik heb zelf geen DSMR-v5 meter, maar een Pi 3 zou het doorgaans wel aan moeten kunnen.
Een advies wat ik je nog kan geven, is om de sleep voor de datalogger (DSMRREADER_DATALOGGER_SLEEP
) op bijvoorbeeld 5 seconden te zetten: https://dsmr-reader.readthedocs.io/en/latest/settings.html#dsmrreader-datalogger-sleep
Hiermee krijg je niet elke seconde een telegram, maar elke 5 seconde. Het is meer dan nauwkeurig genoeg voor alleen de meterstand.
Mocht je echter waarde hechten aan elk telegram per seconde, dan kun je het uiteraard laten staan. Het kost je wel wat performance en op termijn schijfruimte, maar dat is vanzelfsprekend een persoonlijke keuze voor jezelf.
Bedankt voor je reactie @dennissiemensma. Ik vind het zelf ook raar. Is er een manier waarop ik kan controleren of de rest van het database schema wel klopt? Misschien ontbreken er meer indexen of andere objecten...
Je kunt de indexes opvragen met:
sudo su - postgres
psql dsmrreader
\di dsmr_*
Ter referentie, dit is mijn omgeving:
List of relations
Schema | Name | Type | Owner | Table
--------+-----------------------------------------------------------------+-------+------------+-------------------------------------------------
public | dsmr_api_apisettings_pkey | index | dsmrreader | dsmr_api_apisettings
public | dsmr_backend_backendsettings_pkey | index | dsmrreader | dsmr_backend_backendsettings
public | dsmr_backend_emailsettings_pkey | index | dsmrreader | dsmr_backend_emailsettings
public | dsmr_backend_scheduledcall_module_path_d8a435fb_like | index | dsmrreader | dsmr_backend_scheduledcall
public | dsmr_backend_scheduledcall_module_path_key | index | dsmrreader | dsmr_backend_scheduledcall
public | dsmr_backend_scheduledcall_next_call_349e681c | index | dsmrreader | dsmr_backend_scheduledcall
public | dsmr_backend_scheduledcall_pkey | index | dsmrreader | dsmr_backend_scheduledcall
public | dsmr_backend_scheduledprocess_module_55cb894b_like | index | dsmrreader | dsmr_backend_scheduledprocess
public | dsmr_backend_scheduledprocess_module_key | index | dsmrreader | dsmr_backend_scheduledprocess
public | dsmr_backend_scheduledprocess_pkey | index | dsmrreader | dsmr_backend_scheduledprocess
public | dsmr_backup_backupsettings_pkey | index | dsmrreader | dsmr_backup_backupsettings
public | dsmr_backup_dropboxsettings_pkey | index | dsmrreader | dsmr_backup_dropboxsettings
public | dsmr_backup_emailbackupsettings_pkey | index | dsmrreader | dsmr_backup_emailbackupsettings
public | dsmr_consumption_consumptionsettings_pkey | index | dsmrreader | dsmr_consumption_consumptionsettings
public | dsmr_consumption_electrici_phase_voltage_l1_72e3c8f8 | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electrici_phase_voltage_l2_917726c7 | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electrici_phase_voltage_l3_1a9d7c37 | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electricityc_currently_delivered_5bf9be2d_uniq | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electricityco_currently_returned_5f91fed7_uniq | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electricityconsumption_2241f8ee | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electricityconsumption_5714c500 | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electricityconsumption_e90842a6 | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electricityconsumption_pkey | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electricityconsumption_read_at_key | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_energysupplierprice_pkey | index | dsmrreader | dsmr_consumption_energysupplierprice
public | dsmr_consumption_energysupplierprice_start_785e8148_uniq | index | dsmrreader | dsmr_consumption_energysupplierprice
public | dsmr_consumption_gasconsumption_pkey | index | dsmrreader | dsmr_consumption_gasconsumption
public | dsmr_consumption_gasconsumption_read_at_key | index | dsmrreader | dsmr_consumption_gasconsumption
public | dsmr_datalogger_dataloggersettings_pkey | index | dsmrreader | dsmr_datalogger_dataloggersettings
public | dsmr_datalogger_dsmrreading_9d090a40 | index | dsmrreader | dsmr_datalogger_dsmrreading
public | dsmr_datalogger_dsmrreading_pkey | index | dsmrreader | dsmr_datalogger_dsmrreading
public | dsmr_datalogger_dsmrreading_timestamp_1f7020d1_uniq | index | dsmrreader | dsmr_datalogger_dsmrreading
public | dsmr_datalogger_meterstatistics_pkey | index | dsmrreader | dsmr_datalogger_meterstatistics
public | dsmr_datalogger_retentionsettings_pkey | index | dsmrreader | dsmr_datalogger_retentionsettings
public | dsmr_frontend_frontendsettings_pkey | index | dsmrreader | dsmr_frontend_frontendsettings
public | dsmr_frontend_notification_pkey | index | dsmrreader | dsmr_frontend_notification
public | dsmr_mindergas_mindergassettings_pkey | index | dsmrreader | dsmr_mindergas_mindergassettings
public | dsmr_mqtt_jsondaytotalsmqttsettings_pkey | index | dsmrreader | dsmr_mqtt_jsondaytotalsmqttsettings
public | dsmr_mqtt_jsongasconsumptionmqttsettings_pkey | index | dsmrreader | dsmr_mqtt_jsongasconsumptionmqttsettings
public | dsmr_mqtt_jsontelegrammqttsettings_pkey | index | dsmrreader | dsmr_mqtt_jsontelegrammqttsettings
public | dsmr_mqtt_message_pkey | index | dsmrreader | dsmr_mqtt_message
public | dsmr_mqtt_mqttbrokersettings_pkey | index | dsmrreader | dsmr_mqtt_mqttbrokersettings
public | dsmr_mqtt_rawtelegrammqttsettings_pkey | index | dsmrreader | dsmr_mqtt_rawtelegrammqttsettings
public | dsmr_mqtt_splittopicdaytotalsmqttsettings_pkey | index | dsmrreader | dsmr_mqtt_splittopicdaytotalsmqttsettings
public | dsmr_mqtt_splittopicgasconsumptionmqttsettings_pkey | index | dsmrreader | dsmr_mqtt_splittopicgasconsumptionmqttsettings
public | dsmr_mqtt_splittopicmeterstatisticsmqttsettings_pkey | index | dsmrreader | dsmr_mqtt_splittopicmeterstatisticsmqttsettings
public | dsmr_mqtt_splittopictelegrammqttsettings_pkey | index | dsmrreader | dsmr_mqtt_splittopictelegrammqttsettings
public | dsmr_notification_notificationsetting_pkey | index | dsmrreader | dsmr_notification_notificationsetting
public | dsmr_notification_statusnotificationsetting_pkey | index | dsmrreader | dsmr_notification_statusnotificationsetting
public | dsmr_pvoutput_pvoutputaddstatussettings_pkey | index | dsmrreader | dsmr_pvoutput_pvoutputaddstatussettings
public | dsmr_pvoutput_pvoutputapisettings_pkey | index | dsmrreader | dsmr_pvoutput_pvoutputapisettings
public | dsmr_stats_daystatistics_day_key | index | dsmrreader | dsmr_stats_daystatistics
public | dsmr_stats_daystatistics_pkey | index | dsmrreader | dsmr_stats_daystatistics
public | dsmr_stats_electricitystatistics_pkey | index | dsmrreader | dsmr_stats_electricitystatistics
public | dsmr_stats_hourstatistics_hour_start_key | index | dsmrreader | dsmr_stats_hourstatistics
public | dsmr_stats_hourstatistics_pkey | index | dsmrreader | dsmr_stats_hourstatistics
public | dsmr_stats_note_day_83d05681_uniq | index | dsmrreader | dsmr_stats_note
public | dsmr_stats_note_pkey | index | dsmrreader | dsmr_stats_note
public | dsmr_weather_temperaturereading_pkey | index | dsmrreader | dsmr_weather_temperaturereading
public | dsmr_weather_temperaturereading_read_at_key | index | dsmrreader | dsmr_weather_temperaturereading
public | dsmr_weather_weathersettings_pkey | index | dsmrreader | dsmr_weather_weathersettings
(61 rows)
En voor detail-info over een tabel (bijvoorbeeld dsmr_datalogger_dsmrreading
):
sudo su - postgres
psql dsmrreader
\dS dsmr_datalogger_dsmrreading
Voorbeeld:
Table "public.dsmr_datalogger_dsmrreading"
Column | Type | Collation | Nullable | Default
---------------------------------+--------------------------+-----------+----------+---------------------------------------------------------
id | integer | | not null | nextval('dsmr_datalogger_dsmrreading_id_seq'::regclass)
timestamp | timestamp with time zone | | not null |
electricity_delivered_1 | numeric(9,3) | | not null |
electricity_returned_1 | numeric(9,3) | | not null |
electricity_delivered_2 | numeric(9,3) | | not null |
electricity_returned_2 | numeric(9,3) | | not null |
electricity_currently_delivered | numeric(9,3) | | not null |
electricity_currently_returned | numeric(9,3) | | not null |
extra_device_timestamp | timestamp with time zone | | |
extra_device_delivered | numeric(9,3) | | |
processed | boolean | | not null |
phase_currently_delivered_l1 | numeric(9,3) | | |
phase_currently_delivered_l2 | numeric(9,3) | | |
phase_currently_delivered_l3 | numeric(9,3) | | |
phase_currently_returned_l1 | numeric(9,3) | | |
phase_currently_returned_l2 | numeric(9,3) | | |
phase_currently_returned_l3 | numeric(9,3) | | |
phase_voltage_l1 | numeric(4,1) | | |
phase_voltage_l2 | numeric(4,1) | | |
phase_voltage_l3 | numeric(4,1) | | |
Indexes:
"dsmr_datalogger_dsmrreading_pkey" PRIMARY KEY, btree (id)
"dsmr_datalogger_dsmrreading_9d090a40" btree (processed)
"dsmr_datalogger_dsmrreading_timestamp_1f7020d1_uniq" btree ("timestamp")
Bovendien is er nog een probleem: de status pagina doet het nog steeds niet... (geeft timeout)
Dank, ik ga het controleren! Ik zie dat 'ie nu bij mij om de halve seconde slaapt... Die DSMRREADER_DATALOGGER_SLEEP
moet in settings.py
?
Ja, ik had even mogen vermelden dat de instructies bovenaan eerdergenoemde pagina staan: https://dsmr-reader.readthedocs.io/en/latest/settings.html#dsmrreader-datalogger-sleep
Voor de status-pagina kun je het beste even kijken of er een foutmelding staat in de logfile van de webinterface.
/var/log/supervisor/dsmr_webinterface.log
Helaas niet in die log:
[2019-10-30 14:14:53 +0100] [10304] [INFO] Booting worker with pid: 10304
[2019-10-30 14:16:16 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:10304)
[2019-10-30 14:16:17 +0100] [10440] [INFO] Booting worker with pid: 10440
[2019-10-30 14:22:50 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:10440)
[2019-10-30 14:22:51 +0100] [11019] [INFO] Booting worker with pid: 11019
[2019-10-30 14:24:56 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:11019)
[2019-10-30 14:24:58 +0100] [11186] [INFO] Booting worker with pid: 11186
[2019-10-30 21:53:19 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:11186)
[2019-10-30 21:53:21 +0100] [1123] [INFO] Booting worker with pid: 1123
[2019-10-30 21:55:06 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:1123)
[2019-10-30 21:55:07 +0100] [1359] [INFO] Booting worker with pid: 1359
[2019-10-31 20:08:10 +0100] [30061] [CRITICAL] WORKER TIMEOUT (pid:1359)
[2019-10-31 20:08:12 +0100] [1815] [INFO] Booting worker with pid: 1815
Ik vermoed trouwens dat je meer indexes mist dan. De status-pagina vraagt aan de database hoeveel dsmrreadings er zijn met processed=False
. Als daar geen index op staat, is die taak onmogelijk (met jouw hoeveelheid data) binnen de timeout.
Kijk even of de middelste index aanwezig is, uit mijn eerdere voorbeeld hierboven:
Indexes:
"dsmr_datalogger_dsmrreading_pkey" PRIMARY KEY, btree (id)
"dsmr_datalogger_dsmrreading_9d090a40" btree (processed)
"dsmr_datalogger_dsmrreading_timestamp_1f7020d1_uniq" btree ("timestamp")
Indexen:
Schema | Name | Type | Owner | Table
--------+------------------------------------------------------+-------+------------+------------------------------------------------
public | dsmr_backend_backendsettings_pkey | index | dsmrreader | dsmr_backend_backendsettings
public | dsmr_backend_emailsettings_pkey | index | dsmrreader | dsmr_backend_emailsettings
public | dsmr_backend_scheduledprocess_module_55cb894b_like | index | dsmrreader | dsmr_backend_scheduledprocess
public | dsmr_backend_scheduledprocess_module_key | index | dsmrreader | dsmr_backend_scheduledprocess
public | dsmr_backend_scheduledprocess_pkey | index | dsmrreader | dsmr_backend_scheduledprocess
public | dsmr_backup_emailbackupsettings_pkey | index | dsmrreader | dsmr_backup_emailbackupsettings
public | dsmr_consumption_electrici_phase_voltage_l1_72e3c8f8 | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electrici_phase_voltage_l2_917726c7 | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_consumption_electrici_phase_voltage_l3_1a9d7c37 | index | dsmrreader | dsmr_consumption_electricityconsumption
public | dsmr_datalogger_dsmrreading_pkey | index | dsmrreader | dsmr_datalogger_dsmrreading
public | dsmr_datalogger_dsmrreading_timestamp_idx | index | dsmrreader | dsmr_datalogger_dsmrreading
public | dsmr_mqtt_jsongasconsumptionmqttsettings_pkey | index | dsmrreader | dsmr_mqtt_jsongasconsumptionmqttsettings
public | dsmr_mqtt_splittopicgasconsumptionmqttsettings_pkey | index | dsmrreader | dsmr_mqtt_splittopicgasconsumptionmqttsettings
(13 rows)
Da's nie goe...
Is er ergens iets van een script om de database te "fixen"?
Ik denk dat er iets mis is gegaan met de backups dan.
Wat je kunt proberen is twee backups maken:
Klinkt als een goed plan. Is die éne tabel, dsmr_datalogger_dsmrreading
, voldoende voor de variant "alleen alle data van alle metingen"?
Ja in principe wel, want de enige data die binnenkomt, komt direct in je dsmr_datalogger_dsmrreading-tabel en vanuit daar komt consumption en later dag/uur-statistieken.
sudo su - postgres
Volledige dump:
pg_dump -d dsmrreader | gzip --fast > dsmr-reader-full.sql.gz
Data-only:
pg_dump -d dsmrreader --data-only -t dsmr_datalogger_dsmrreading | gzip --fast > dsmr_datalogger_dsmrreading-data.sql.gz
Check even of je qua disk space het redt trouwens. En of de backups inhoudelijk ook data hebben.
Cool ik ga het doen Dennis. Zal niet meer vandaag worden, maar ik zal nog laten weten wat het resultaat is. Bedankt voor het meedenken en je hulp!
Als je dit hebt gedaan en zeker weet dat de oude DB weg kan:
sudo supervisorctl stop all
sudo su - postgres
# !!! weg = weg!
dropdb dsmrreader
createdb -O dsmrreader dsmrreader
logout
sudo su - dsmr
# DB schema via migraties
./manage.py migrate
logout
sudo su - postgres
# Data inlezen
zcat dsmr_datalogger_dsmrreading-data.sql.gz | psql -d dsmrreader
logout
sudo supervisorctl start all
Uit mn hoofd dan, maar ik heb het idee dat je technisch genoeg bent om je ermee te redden.
Yep komt goed, dank je!
Hoi @dennissiemensma, ik heb de data-only restore gedaan en dat lijkt grotendeels te werken. Nu is het probleem alleen dat de statistieken van de oude data niet meer worden opgebouwd. Het lijkt wel of 'ie niet verder terug in de tijd kijkt dan het moment dat ik 'm heb geïnstalleerd:
dsmrreader=> select id,hour_start from dsmr_stats_hourstatistics;
id | hour_start
----+------------------------
1 | 2019-11-01 06:00:00+01
2 | 2019-11-01 07:00:00+01
3 | 2019-11-01 08:00:00+01
4 | 2019-11-01 09:00:00+01
5 | 2019-11-01 10:00:00+01
6 | 2019-11-01 11:00:00+01
7 | 2019-11-01 12:00:00+01
8 | 2019-11-01 13:00:00+01
9 | 2019-11-01 14:00:00+01
10 | 2019-11-01 15:00:00+01
11 | 2019-11-01 16:00:00+01
12 | 2019-11-01 17:00:00+01
13 | 2019-11-01 18:00:00+01
14 | 2019-11-01 19:00:00+01
15 | 2019-11-01 20:00:00+01
16 | 2019-11-01 21:00:00+01
17 | 2019-11-01 22:00:00+01
18 | 2019-11-01 23:00:00+01
19 | 2019-11-02 00:00:00+01
(19 rows)
Kan dat kloppen? Is er ergens een instelling / timestamp waar 'ie naar kijkt die ik nog goed moet zetten? Dank je!
Je kunt de applicatie even stoppen, alle statistieken weggooien, alle consumptie weggooien en dan alle telegrammen op onverwerkt zetten. Hij zou dan alles van dag 0 opnieuw moeten berekenen.
Doe dit uiteraard alleen als je een extra backup hebt, gezien ik niet weet in welke staat de dataset exact is en je anders verder van huis bent.
sudo supervisorctl stop dsmr_backend
sudo su - postgres
psql dsmrreader
truncate dsmr_stats_daystatistics;
truncate dsmr_stats_hourstatistics;
truncate dsmr_consumption_electricityconsumption;
truncate dsmr_consumption_gasconsumption;
update dsmr_datalogger_dsmrreading set processed = false where processed = true;
CTRL+D
logout
sudo supervisorctl start dsmr_backend
Als het goed is is nu alles leeg en probeert die op de achtergrond allees opnieuw te berekenen.
Je kunt af en toe even in de DB kijken of het aantal onverwerkte telegrammen terugloopt:
select count(id) from dsmr_datalogger_dsmrreading where processed = false;
Ah ja processed
kolom klinkt logisch. Ga 't proberen! 👍
@dennissiemensma Vandaag zag ik dat eindelijk alles weer opnieuw "processed" was. Ik merkte alleen dat de index op processed
op dsmr_datalogger_dsmrreading
heel traag was. Uiteindelijk reindex database dsmrreader
gedaan. Dat helpt voor de processed
index, maar de statuspagina is nog steeds zo traag dat 'ie een timeout geeft. Nog enig idee waar ik naar kan kijken? De rest van de applicatie lijkt nu wel goed te werken.
Ik vind het wel nog gek dat select count(id) from dsmr_datalogger_dsmrreading
erg lang duurt ondanks de primary key index trouwens.
dsmrreader=> explain select count(id) from dsmr_datalogger_dsmrreading;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Finalize Aggregate (cost=318284.18..318284.19 rows=1 width=8)
-> Gather (cost=318283.97..318284.18 rows=2 width=8)
Workers Planned: 2
-> Partial Aggregate (cost=317283.97..317283.98 rows=1 width=8)
-> Parallel Index Only Scan using dsmr_datalogger_dsmrreading_pkey on dsmr_datalogger_dsmrreading (cost=0.43..304400.48 rows=5153395 width=4)
(5 rows)
Ik kan me herinneren dat PostgreSQL sowieso traag is met counts op datasets zonder where condition: https://wiki.postgresql.org/wiki/Slow_Counting
Wellicht moet ik eens kijken of ik er een conditionele count van kan maken. Je kunt eens proberen of het groot verschil maakt door een count te doen met processed = true
.
Ja die pagina had ik inderdaad ook gevonden. Ik heb even wat experimentjes gedaan:
dsmrreader=> select count(*) from dsmr_datalogger_dsmrreading;
count
----------
12407415
(1 row)
Time: 29287.462 ms (00:29.287)
dsmrreader=> select count(*) from dsmr_datalogger_dsmrreading where processed=true;;
count
----------
12407425
(1 row)
Time: 24510.569 ms (00:24.511)
Time: 0.538 ms
dsmrreader=> select count(id) from dsmr_datalogger_dsmrreading;
count
----------
12407556
(1 row)
Time: 34030.089 ms (00:34.030)
dsmrreader=> select count(processed) from dsmr_datalogger_dsmrreading;
count
----------
12407604
(1 row)
Time: 13135.208 ms (00:13.135)
dsmrreader=> create index dsmr_datalogger_dsmrreading_id on dsmr_datalogger_dsmrreading(id);
CREATE INDEX
Time: 206516.333 ms (03:26.516)
dsmrreader=> select count(id) from dsmr_datalogger_dsmrreading;
count
----------
12407645
(1 row)
Time: 38060.619 ms (00:38.061)
dsmrreader=> select count(*) from dsmr_datalogger_dsmrreading;
count
----------
12407668
(1 row)
Time: 14342.425 ms (00:14.342)
Maar dit is natuurlijk wel testen van de koude grond, zonder rekening te houden met caching en dat soort dingen. Een where
clause lijkt trouwens in dit geval niet veel effect te hebben:
dsmrreader=> select count(processed) from dsmr_datalogger_dsmrreading;
count
----------
12407744
(1 row)
Time: 21168.233 ms (00:21.168)
dsmrreader=> select count(processed) from dsmr_datalogger_dsmrreading;
count
----------
12407757
(1 row)
Time: 30329.372 ms (00:30.329)
dsmrreader=> select count(processed) from dsmr_datalogger_dsmrreading where processed=true;
count
----------
12407772
(1 row)
Time: 31235.176 ms (00:31.235)
Raar dat die tweede 10 seconden langer duurt dan de eerste...
Misschien is het gebruik van schattingen een optie?
dsmrreader=> select count(*) from dsmr_datalogger_dsmrreading;
count
----------
12407988
(1 row)
Time: 24374.681 ms (00:24.375)
dsmrreader=> SELECT reltuples::BIGINT AS approximate_row_count FROM pg_class WHERE relname = 'dsmr_datalogger_dsmrreading';
approximate_row_count
-----------------------
12407963
(1 row)
Time: 21.774 ms
Bedankt voor je onderzoek. Opzich zou dat kunnen, al gebruik ik liever het ORM van Django ipv hardcoded queries te doen.
Wellicht dat ik dan beter de count helemaal weg kan halen en de status bepalen op basis van tijdsinterval sinds laatste verwerking oid.
Hi Dennis/Stefan,
ik heb exact hetzelfde probleem (logger gebruikt dezelfde id's na terugzetten DB, dus foutmelding 'dsmr_datalogger.models.reading.DsmrReading.MultipleObjectsReturned: get() returned more than one DsmrReading -- it returned 2!').
Mijn SD kaartje was corrupt, dus nieuwe installatie, database teruggezet volgens instructies en nu wodt er dus niet meer gelogd. Wat zijn de stappen naar een werkende DSMR met behoud van data?
OK, ik heb de 'data-only' restore gedaan en alle telegrammen worden weer geprocessed. Niet alle settings uit de backup zijn overgekomen (i.i.g niet de MQTT & Weer instellingen)
Werkt het inmiddels weer?
Ik denk het: ik heb alleen nog geen daily stats, die komen vannacht nog hoop ik. Overigens gaat het denk ik fout als de telegrammen (ik had er 650.000) verwerkt worden tijdens de nachtelijke daily stats run. Ik had in elk geval maar een handvol daily stats. Ik heb daarom nog maar eens het hele proces herhaald. Alle telegrammen zijn verwerkt, alleen de statistieken zijn allemaal nog weg. Die hoop ik vannacht terug te krijgen...
Mijn vertrouwen in de data backup/restore is enorm gedaald: het merendeel van de instellingen is niet teruggezet, alle notes zijn verdwenen. 't is op dit moment zeker niet zo simpel als gedocumenteerd.
@pa1pdr Dat van die onvolledige backup had ik ook, maar eerlijk is eerlijk, dat komt natuurlijk ook door de corrupte SD kaart. Je kan wel je vraagtekens zetten bij het nut van roterende "laatste 7 dagen" backups. @dennissiemensma Misschien een lichtere variant van zoiets maken? https://serverfault.com/a/575169
Verder @pa1pdr ter info: het herstellen van alle statistieken duurde bij mij twee weken, dus wees gewaarschuwd 😉
Ik had verwacht dat de backups volledig zouden zijn, anders had ik wel een bacula backup teruggezet. Die zijn nu eenmaal wat ouder (1 week) dan de dagelijkse die DSMR maakt. Dank voor de statistiek tip, anders had ik het al vrij snel opgegeven: ik ben niet zo'n geduldig tiep 😉
@pa1pdr bedankt voor je terugkoppeling. Ik heb in dat geval wel iets meer informatie nodig van wat er precies speelt. Als je een oncorrupte, volledige backup hebt, staat daar alles in wat nodig is en dan zou het terugzetten zeker net zo makkelijk moeten zijn als in de documentatie. Het is daarnaast belangrijk dat je in ieder geval DSMR-reader niet initialiseert (migraties draait) of start totdat je de backup hebt teruggezet, want anders krijg je sowieso dubbele records en fouten. Wellicht kun je in die hoek nog wat zoeken.
@svdo Het omzeilen van corrupte data is een vrij complexe taak geworden en dus waag ik mij er niet meer aan.
Ik denk dat het uiteindelijk een kwestie gaat zijn van voorlichting naar gebruikers toe dat ze er zelf voor moeten zorgen dat de backup's ergens veilig staan. Daarbij is het uiteraard mijn verantwoordelijkheid om genoeg opties uit te werken of te wijzen op alternatieven.
Ja dat is inderdaad een moeras. Het was alleen wel zo dat ik nu ook op het verkeerde been was gezet, ik had een beetje zo'n gevoel van "hij doet backups dus het zal wel goed zijn". Ik had ook al eerder gezien dat dat alleen de laatste paar dagen is, dus ik reken je wat dat betreft helemaal niks aan hoor :) Maar het is inderdaad wellicht wel slim om daar in de interface en documentatie wat explicieter over te zijn. Ik zou zelfs overwegen om het standaard UIT te zetten en in de interface een waarschuwing te tonen: "let op: backups zijn nog niet geconfigureerd". Het probleem is namelijk ook een beetje dat de backups zelf ook weer bijdragen aan extra snelle slijtage van de SD kaart (hoewel ik geen idee heb hoeveel). Geen kritiek hè, ik probeer alleen mee te denken! 😉
@svdo Hetzelfde hier: ik dacht, ik heb tenminste 5 dagen backups van DSMR + wekelijks van bacula, dus dat moet goed gaan. Het terugzetten van een volledige DSMR backup (na supervisor stop all) leverde de MultipleObjects fout op (na starten datalogger). Dus ik denk dat er iets mis is gegaan met de waarde van dsmr_datalogger_dsmrreading_id_seq....
De verdere instructie om 'pg_dump -d dsmrreader --data-only -t dsmr_datalogger_dsmrreading' in te lezen levert natuurlijk alleen een lege database met readings op, dus zo gek is het achteraf niet dat alle andere tabellen leeg zijn: works as designed.
@dennissiemensma : je hebt instructies hoe je postgres naar een andere directory // mounted disk kunt laten schrijven, dit om wear leveling op de SD kaartjes tegen te gaan. Is het ook mogelijk dat DSMR met een postgres op een andere server (ipv locaal) communiceert? Scheelt een hoop writes schat ik...
@pa1pdr je bent daar zelf helemaal vrij in.
Bij het initialiseren van DSMR-reader heb je ergens een dsmrreader/settings.py
aangemaakt. De waarden daarin kun je rustig aanpassen qua database. Houd er wel rekening mee dat doorgaans database en applicatie op dezelfde machine staan, maar dat is dus geen vereiste hier.
Duidelijk, dank!
Hallo! Enorm bedankt voor dsmrreader, ik ben er heel erg blij mee!!! Ik heb een probleempje:
Wat gebruik je?
v2.9
RaspberryPi 3b+
v5
(denk ik?)Bij fouten
Ik gebruik sinds begin dit jaar dsmrreader. Ik had wat problemen met de SD kaart van mijn Raspberry, dus ik heb van de week de boel opnieuw geïnstalleerd op een externe harddisk. Ik heb een backup teruggezet. Twee vragen:
/var/log/supervisor/dsmr_datalogger-stderr---supervisor-rkb79j.log
. Is dit iets om me zorgen over te maken, kan ik het oplossen?