Mehr Datensätze -> langsamer.
Aber warum hat der neue p4d so extrem viel mehr Datensätze nach dem Import des Backups?
Es gibt 5.174 Antworten in diesem Thema, welches 1.798.690 mal aufgerufen wurde. Der letzte Beitrag () ist von meute.
Mehr Datensätze -> langsamer.
Aber warum hat der neue p4d so extrem viel mehr Datensätze nach dem Import des Backups?
das weiß ich nicht, bei mir kommen immer exakt die an welche ich importiere. Wenn da zu viele drin sind sollte das auf jeden Fall bereinigt werden.
Zur den Konfig Optionen und Konfig Files für mysql (/etc/mysql/...) googel mal da gibt es tausende howtos.
das weiß ich nicht, bei mir kommen immer exakt die an welche ich importiere.
Bei mir sind die Daten anscheind mehrfach drin nach dem Import
Muss ich später mal sehen, ob ich da was rausfinde.
Zur den Konfig Optionen und Konfig Files für mysql (/etc/mysql/...) googel mal da gibt es tausende howtos.
Ich google schon die ganze Zeit.
Das habe ich mir gebastelt.
Leider noch nicht auf lesbare Formate KB/MB/GB konvertiert.
SELECT VARIABLE_NAME, SESSION_VALUE, GLOBAL_VALUE, DEFAULT_VALUE FROM INFORMATION_SCHEMA.SYSTEM_VARIABLES
-> WHERE
-> VARIABLE_NAME LIKE 'key_buffer_size' OR
-> VARIABLE_NAME LIKE 'max_allowed_packet' OR
-> VARIABLE_NAME LIKE 'thread_stack' OR
-> VARIABLE_NAME LIKE 'thread_cache_size' OR
-> VARIABLE_NAME LIKE 'max_connections' OR
-> VARIABLE_NAME LIKE 'query_cache_limit' OR
-> VARIABLE_NAME LIKE 'query_cache_size' OR
-> VARIABLE_NAME LIKE 'general_log_file' OR
-> VARIABLE_NAME LIKE 'log_warnings' OR
-> VARIABLE_NAME LIKE 'expire_logs_days' OR
-> VARIABLE_NAME LIKE 'max_binlog_size' OR
-> VARIABLE_NAME LIKE 'character-set-server' OR
-> VARIABLE_NAME LIKE 'collation-server' OR
-> VARIABLE_NAME LIKE 'innodb_buffer_pool_size'
-> ORDER BY VARIABLE_NAME;
+-------------------------+---------------+-------------------+---------------+
| VARIABLE_NAME | SESSION_VALUE | GLOBAL_VALUE | DEFAULT_VALUE |
+-------------------------+---------------+-------------------+---------------+
| EXPIRE_LOGS_DAYS | NULL | 10.000000 | 0.000000 |
| GENERAL_LOG_FILE | NULL | froelingp4d85.log | |
| INNODB_BUFFER_POOL_SIZE | NULL | 134217728 | 134217728 |
| KEY_BUFFER_SIZE | NULL | 134217728 | 134217728 |
| LOG_WARNINGS | 2 | 2 | 2 |
| MAX_ALLOWED_PACKET | 16777216 | 16777216 | 16777216 |
| MAX_BINLOG_SIZE | NULL | 1073741824 | 1073741824 |
| MAX_CONNECTIONS | NULL | 151 | 151 |
| QUERY_CACHE_LIMIT | NULL | 1048576 | 1048576 |
| QUERY_CACHE_SIZE | NULL | 1048576 | 1048576 |
| THREAD_CACHE_SIZE | NULL | 151 | 256 |
| THREAD_STACK | NULL | 299008 | 299008 |
+-------------------------+---------------+-------------------+---------------+
12 rows in set (0,007 sec)
Alles anzeigen
das weiß ich nicht, bei mir kommen immer exakt die an welche ich importiere. Wenn da zu viele drin sind sollte das auf jeden Fall bereinigt werden.
Ich habe nun rückwirkend stichprobenartig aus der Tabelle samples die Datensätze einzelner Tage ermittelt.
Je Tag sind es knapp 70.000 Datensätze.
Kommt das in etwa hin?
Oder müsste es bei den alten Daten weniger sein?
Hier lief schon der neue p4d:
MariaDB [p4]> select count(*) from samples
-> where time > "2025-03-16 00:00:00"
-> and time < "2025-03-16 23:59:59";
+----------+
| count(*) |
+----------+
| 66720 |
+----------+
Ab Hier lief noch der alte p4d:
MariaDB [p4]> select count(*) from samples
-> where time > "2025-01-01 00:00:00"
-> and time < "2025-01-01 23:59:59";
+----------+
| count(*) |
+----------+
| 69264 |
+----------+
'Anzahl Datensätze an Tag' = 'Sekunden am Tag' / 'dein Aufzeichnungsintervall in Sekunden' * 'aktive valuefacts'
lösche doch einfach alle samples welche eine time haben die kleiner als die ist an dem du den 'neuen' gestartet hast und importiere nochmal neu
wobei, da muss mehr schief gegangen sein bei Aufbau / Import denn selbst wenn du es 10 Mail importierst sollte es durch dem Primar Schlüssel keine doppelten Datensätze geben.
PRIMARY KEY (`address`,`type`,`aggregate`,`time`),
lösche doch einfach alle samples welche eine time haben die kleiner als die ist an dem du den 'neuen' gestartet hast und importiere nochmal neu
Bleiben nach dem Import wohl die neuen Datensätze erhalten?
Ich dachte, es wird beim Import alles vorhandene gelöscht?
wenn du vom Export File nur den Teil mit den Imports verwendest bleibt alles erhalten.
Wäre nur interessant ob mit der Tabelle ansonsten alles okay ist - primary key, etc.
Wäre nur interessant ob mit der Tabelle ansonsten alles okay ist - primary key, etc.
Wie kann ich das prüfen?
lass dir mal die Struktur ausgeben und passte sie. Hast du die mal die 'zu vielen' Rows angesehen, unterscheiden die sich im Primär Schlüssel? Hast du eine Idee wie es zu diesen zusätzlichen Rows kommt?
Wenn du dir sicher bist das die Tabelle okay ist kannst du dir das natürlich sparen
Hast du eine Idee wie es zu diesen zusätzlichen Rows kommt?
Ich habe kein Idee, wie es zu den zusätzlichen Rows kommt.
Ich habe jetzt folgendes gemacht.
Dump vom neuen p4d erzeugt.
Insert-Strings der neuen Daten seit 12.03.2025 von samples-dump.sql zum alten samples-dump.sql hinzugefügt.
p4d gestoppt.
Im Moment läuft der Import von samples-dump.sql.
lass dir mal die Struktur ausgeben und passte sie. Hast du die mal die 'zu vielen' Rows angesehen, unterscheiden die sich im Primär Schlüssel?
Ich weiß aber nicht, wie ich das prüfen kann.
Struktur ausgeben?
Primary Key prüfen?
Ich habe den ganzen Nachmittag schon gegoogelt.
Ich habe jetzt folgendes gemacht.
Dump vom neuen p4d erzeugt.
Insert-Strings der neuen Daten seit 12.03.2025 von samples-dump.sql zum alten samples-dump.sql hinzugefügt.
p4d gestoppt.
Im Moment läuft der Import von samples-dump.sql.
p4d läuft wieder.
Die Anzahl der Datensätze in samples ist wie vorher.
Aber keine Verbesserung:
2025-03-19T17:56:54.373601+01:00 froelingp4d85 p4d: duration 'loop total' was (7310ms)
2025-03-19T17:56:54.373492+01:00 froelingp4d85 p4d: duration 'afterUpdate' was (5664ms)
2025-03-19T17:56:54.373223+01:00 froelingp4d85 p4d: duration 'P4d::calcStateDuration (as part of afterUpdate)' was (3018ms)
2025-03-19T17:56:51.354549+01:00 froelingp4d85 p4d: duration 'P4d::updateErrors (as part of afterUpdate)' was (2645ms)
2025-03-19T17:56:48.708562+01:00 froelingp4d85 p4d: duration 'updateInputs' was (1ms)
2025-03-19T17:56:48.708109+01:00 froelingp4d85 p4d: duration 'storeSamples' was (139ms)
2025-03-19T17:56:48.568958+01:00 froelingp4d85 p4d: duration 'process' was (0ms)
2025-03-19T17:56:48.568840+01:00 froelingp4d85 p4d: duration 'updateScriptSensors' was (1ms)
2025-03-19T17:56:48.557257+01:00 froelingp4d85 p4d: duration 'updateSensors' was (1494ms)
2025-03-19T17:56:48.557048+01:00 froelingp4d85 p4d: duration 'P4d::updateSensors' was (1494ms)
2025-03-19T17:56:47.063938+01:00 froelingp4d85 p4d: duration 'updateWeather' was (0ms)
2025-03-19T17:56:47.063348+01:00 froelingp4d85 p4d: duration 'updateInputs' was (0ms)
Alles anzeigen
Wie viele Datensätze sind denn in Deiner samples?
Bei meinem Server habe ich festgestellt, daß die Datenbank irgendwann zu langsam wird, wenn zu viele Datensätze gespeichert sind. Dann funktioniert p4d nicht mehr. Es werden keine Daten mehr geschrieben und auch keine im Web-Interface angezeigt. Das Problem konnte ich lösen, indem ich die Datenaggregierung eingeschaltet habe.
Historie (Tage) = 365
danach aggregieren über (Minuten) = 15 <-- war im Standard nicht aktiv
MariaDB [p4]> show create table samples;
| samples | CREATE TABLE `samples` (
`address` int(4) unsigned NOT NULL,
`type` varchar(8) NOT NULL,
`aggregate` varchar(1) NOT NULL,
`time` datetime NOT NULL,
`inssp` int(10) DEFAULT NULL,
`updsp` int(10) DEFAULT NULL,
`value` float(14,2) DEFAULT NULL,
`text` varchar(50) DEFAULT NULL,
`samples` int(3) DEFAULT NULL,
PRIMARY KEY (`address`,`type`,`aggregate`,`time`),
KEY `idxtime` (`time`),
KEY `idxtype` (`type`),
KEY `idxaggregate` (`aggregate`),
KEY `idxaddr_type_time` (`address`,`type`,`time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci
Alles anzeigen
24.660.291 Rows (alles seit 2013-06-14)
MariaDB [p4]> select count(*) from samples;
+----------+
| count(*) |
+----------+
| 24660291 |
+----------+
das bei dir nach dem Import so viel mehr Rows da sind als beim Export ist unlogisch
Ich habe den alten p4d wieder eingeschaltet und den Inhalt der Tabelle samples geprüft.
Im alten p4d sind es auch 108.235.447 Rows.
Installiert wurde der alte immer mit dem Package auf einem Raspi 4B.
p4d sammelt die Daten seit August 2020, also knapp 5 Jahre.
select count(*) from samples;
+-----------+
| count(*) |
+-----------+
| 108235447 |
+-----------+
Passt dann dort schon was nicht?
In der alten p4d-GUI wurden aber nur 28.614.145 Rows angezeigt.
Siehe Screenshot.
Bei meinem Server habe ich festgestellt, daß die Datenbank irgendwann zu langsam wird, wenn zu viele Datensätze gespeichert sind.
Das Problem konnte ich lösen, indem ich die Datenaggregierung eingeschaltet habe.
Historie (Tage) = 365
danach aggregieren über (Minuten) = 15 <-- war im Standard nicht aktiv
Wie kann ich das prüfen?
Wie kann ich das aktivieren?
Ich habe den alten p4d wieder eingeschaltet und den Inhalt der Tabelle samples geprüft.
Im alten p4d sind es auch 108.235.447 Rows.
Installiert wurde der alte immer mit dem Package auf einem Raspi 4B.
p4d sammelt die Daten seit August 2020, also knapp 5 Jahre.
Ich habe den alten p4d nun mit SHOW TABLE STATUS in p4; geprüft.
Dort werden bei samples nur 28.614.145 Rows angezeigt.
Wo ist da der Wurm drin?
MariaDB [p4]> SHOW TABLE STATUS in p4;
+------------------+--------+---------+------------+----------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+--------------------+---------+------------------+-----------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment | Max_index_length | Temporary |
+------------------+--------+---------+------------+----------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+--------------------+---------+------------------+-----------+
| config | InnoDB | 10 | Dynamic | 65 | 252 | 16384 | 0 | 0 | 0 | NULL | 2020-09-23 18:31:57 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| dashboards | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 0 | 0 | 3 | 2021-12-25 12:35:47 | NULL | NULL | utf8_general_ci | NULL | row_format=DYNAMIC | | 0 | N |
| dashboardwidgets | InnoDB | 10 | Dynamic | 83 | 592 | 49152 | 0 | 0 | 0 | NULL | 2021-12-25 12:35:47 | NULL | NULL | utf8_general_ci | NULL | row_format=DYNAMIC | | 0 | N |
| deconzl | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 0 | 0 | 1 | 2021-12-25 12:35:47 | NULL | NULL | utf8_general_ci | NULL | row_format=DYNAMIC | | 0 | N |
| deconzs | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 0 | 0 | 1 | 2021-12-25 12:35:47 | NULL | NULL | utf8_general_ci | NULL | row_format=DYNAMIC | | 0 | N |
| errors | InnoDB | 10 | Dynamic | 91 | 180 | 16384 | 0 | 0 | 0 | 98 | 2020-06-07 10:02:10 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| groups | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 0 | 0 | 2 | 2020-06-07 10:02:10 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| hmsysvars | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 16384 | 0 | NULL | 2020-06-07 10:02:10 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| homematic | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 0 | 0 | 1 | 2021-12-25 12:35:47 | NULL | NULL | utf8_general_ci | NULL | row_format=DYNAMIC | | 0 | N |
| jobs | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 32768 | 0 | 1 | 2020-08-22 16:51:17 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| menu | InnoDB | 10 | Dynamic | 2412 | 108 | 262144 | 0 | 0 | 0 | 2547 | 2021-01-08 14:38:01 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| peaks | InnoDB | 10 | Dynamic | 85 | 192 | 16384 | 0 | 0 | 0 | NULL | 2021-12-25 12:35:47 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| pellets | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 0 | 0 | 1 | 2021-02-14 12:26:37 | NULL | NULL | utf8_general_ci | NULL | row_format=DYNAMIC | | 0 | N |
| samples | InnoDB | 10 | Dynamic | 28614145 | 63 | 1805631488 | 0 | 2600402944 | 7340032 | NULL | 2021-12-25 12:57:27 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| schemaconf | InnoDB | 10 | Dynamic | 55 | 297 | 16384 | 0 | 0 | 0 | NULL | 2021-12-25 12:57:27 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| scripts | InnoDB | 10 | Dynamic | 2 | 8192 | 16384 | 0 | 16384 | 0 | 5 | 2020-06-07 10:02:10 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| sensoralert | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 0 | 0 | 1 | 2021-12-25 12:57:27 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| smartconfig | InnoDB | 10 | Dynamic | 49 | 334 | 16384 | 0 | 0 | 0 | NULL | 2020-06-07 10:02:10 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| states | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 0 | 0 | NULL | 2021-12-25 12:57:27 | NULL | NULL | utf8_general_ci | NULL | row_format=DYNAMIC | | 0 | N |
| timeranges | InnoDB | 10 | Dynamic | 224 | 219 | 49152 | 0 | 0 | 0 | NULL | 2020-06-07 10:02:10 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| users | InnoDB | 10 | Dynamic | 0 | 0 | 16384 | 0 | 0 | 0 | NULL | 2020-09-23 18:31:59 | NULL | NULL | utf8_general_ci | NULL | row_format=DYNAMIC | | 0 | N |
| valuefacts | InnoDB | 10 | Dynamic | 567 | 346 | 196608 | 0 | 0 | 0 | NULL | 2022-01-06 11:53:47 | NULL | NULL | utf8_general_ci | NULL | | | 0 | N |
| valuetypes | InnoDB | 10 | Dynamic | 7 | 2340 | 16384 | 0 | 0 | 0 | NULL | 2021-12-27 09:24:59 | NULL | NULL | utf8_general_ci | NULL | row_format=DYNAMIC | | 0 | N |
+------------------+--------+---------+------------+----------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+--------------------+---------+------------------+-----------+
Alles anzeigen
Das im Web Interface was falschen anzeigt wird ist komisch muss ich mir mal ansehen.
Bis dahin verlasse dich auf das select count, wenn du damit das richtige bekommst also es im Prinzip mit dem alten übereinstimmt ist m.E. alle in Ordnung.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!