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.
Aber warum bringt dann SHOW TABLE STATUS in p4; nur 28.614.145 Rows?
Siehe #5.159
Es gibt 5.174 Antworten in diesem Thema, welches 1.798.576 mal aufgerufen wurde. Der letzte Beitrag () ist von meute.
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.
Aber warum bringt dann SHOW TABLE STATUS in p4; nur 28.614.145 Rows?
Siehe #5.159
Gute Frage, weiß ich nich. Kannst du mal in einen mysql Forum recherchieren wäre wirklich interessant zu wissen
Alles anzeigenBei 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?
Im allgemeinen Setup auf der Weboberfläche des p4d sind diese Einstellungen zu finden, zumindest in der alten Version 0.7.8, die bei mir noch läuft.
Alles anzeigenAlles anzeigenBei 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?
Im allgemeinen Setup auf der Weboberfläche des p4d sind diese Einstellungen zu finden, zumindest in der alten Version 0.7.8, die bei mir noch läuft.
Ach so, Du meinst die Konfig in der p4d-GUI.
Da ist das bei mir auch so eingestellt.
Dürfte die Standardeinstellung sein. Ich habe da nie dran rumgedreht.
Siehe #5131
Gute Frage, weiß ich nich. Kannst du mal in einen mysql Forum recherchieren wäre wirklich interessant zu wissen
Nachfolgend die Info zum Grund, warum die beiden SQL-Statements
select count(*) from samples;
show table status in p4;
unterschiedliche rows anzeigen.
Der Wert bei select count(*) from samples; ist korrekt.
Man kann das Anzeige-Problem bei show table status in p4; wie folgt beheben:
analyze table samples;
Danach zeigt show table status in p4; die korrekte Anzahl an rows in der Tabelle samples an.
Zitat aus dem MySQL Reference Manual:
For InnoDB tables, SHOW TABLE STATUS does not give accurate statistics except for the physical size reserved by the table. The row count is only a rough estimate used in SQL optimization.
Für InnoDB-Tabellen liefert SHOW TABLE STATUS keine genauen Statistiken, außer der von der Tabelle reservierten physischen Größe. Die Zeilenanzahl ist nur eine grobe Schätzung und wird in der SQL-Optimierung verwendet.
Lektüre:
MySQL :: MySQL 8.0 Reference Manual :: 15.7.7.38 SHOW TABLE STATUS Statement
Timings? Nö, sagt mir im Moment auch nichts.
schau mal hier da hatte ich das erläutert, vielleicht hat ja jemand Lust und Zeit das im github Wiki zu verewigen
Ich habe das mal im p4d-Wiki verewigt.
Schau Dir das bitte mal an, ob so OK.
Webseiten-Probleme im p4d-Wiki
Nochmal zu meinem Problem mit den "LoopTimings".
Der neue p4d läuft nicht mehr auf Raspi, sondern in einem Ubuntu LXC-Container auf Proxmox auf einem Thin Client.
Intel(R) Celeron(R) J4105 CPU @ 1.50GHz
Cores: 4
4 GB RAM
Ich habe jetzt diverse MariaDB-Variablen anhand Deiner Einstellung angepasst.
Nicht alle, aber einige.
Die "LoopTimings" haben sich etwas verbessert.
Verbesserung 'loop total' von (7310ms) auf (5713ms)
Verbesserung 'P4d::calcStateDuration (as part of afterUpdate)' von (3018ms) auf (1693ms)
Bei Dir dauert calcStateDuration aber nur 300-400 ms.
Hast Du noch eine Idee, welcher Parameter für calcStateDuration entscheidend ist?
Info zur Variable max_allowed_packet
Bei Dir: max_allowed_packet=1G
Ich habe zum Test kurzzeitig max_allowed_packet=500M gesetzt.
Die Erhöhung bringt aber null Verbesserung, deshalb bin ich wieder auf default max_allowed_packet=16M
MariaDB-Variablen horchi
innodb_buffer_pool_size = 10G
key_buffer_size = 10M
max_allowed_packet = 1G
max_binlog_size = 100M
max_connections = 200
query_cache_limit = 1M
query_cache_size = 8M
thread_cache_size = 8
thread_stack = 192K
Meine angepassten MariaDB-Variablen.
innodb_buffer_pool_size
key_buffer_size
max_binlog_size
query_cache_size
Die "LoopTimings" haben sich etwas verbessert.
Verbesserung 'loop total' von (7310ms) auf (5713ms)
Verbesserung 'P4d::calcStateDuration (as part of afterUpdate)' von (3018ms) auf (1693ms)
innodb_buffer_pool_size = 2G
key_buffer_size = 10M
max_allowed_packet = 16M
max_binlog_size = 100M
max_connections = 151
query_cache_limit = 1M
query_cache_size = 8M
thread_cache_size = 151
thread_stack = 292K
2025-03-24T12:21:16.756921+01:00 froelingp4d85 p4d: duration 'loop total' was (5713ms)
2025-03-24T12:21:16.756839+01:00 froelingp4d85 p4d: duration 'afterUpdate' was (4096ms)
2025-03-24T12:21:16.756663+01:00 froelingp4d85 p4d: duration 'P4d::calcStateDuration (as part of afterUpdate)' was (1693ms)
2025-03-24T12:21:15.064489+01:00 froelingp4d85 p4d: duration 'P4d::updateErrors (as part of afterUpdate)' was (2403ms)
2025-03-24T12:21:12.660864+01:00 froelingp4d85 p4d: duration 'updateInputs' was (0ms)
2025-03-24T12:21:12.660450+01:00 froelingp4d85 p4d: duration 'storeSamples' was (23ms)
2025-03-24T12:21:12.637317+01:00 froelingp4d85 p4d: duration 'process' was (0ms)
2025-03-24T12:21:12.637196+01:00 froelingp4d85 p4d: duration 'updateScriptSensors' was (1ms)
2025-03-24T12:21:12.631333+01:00 froelingp4d85 p4d: duration 'updateSensors' was (1587ms)
2025-03-24T12:21:12.631124+01:00 froelingp4d85 p4d: duration 'P4d::updateSensors' was (1587ms)
2025-03-24T12:21:11.044771+01:00 froelingp4d85 p4d: duration 'updateWeather' was (0ms)
2025-03-24T12:21:11.044187+01:00 froelingp4d85 p4d: duration 'updateInputs' was (0ms)
Alles anzeigen
Meine ursprünglichen Standard-MariaDB-Variablen, mit hohen "LoopTimings"
innodb_buffer_pool_size = 128M
key_buffer_size = 128M
max_allowed_packet = 16M
max_binlog_size = 1GB
max_connections = 151
query_cache_limit = 1M
query_cache_size = 1M
thread_cache_size = 151
thread_stack = 292K
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
Nein bin leider auch kein DB tuning Spezialist.
Wenn du calcStateDuration nicht benötigst kann ich es abschaltbar machen.
Wenn du calcStateDuration nicht benötigst kann ich es abschaltbar machen.
Was bewirkt calcStateDuration und updateErrors?
EDIT:
Passt der Wiki-Eintrag?
EDIT:
Passt der Wiki-Eintrag?
ja passt
Das ging noch nicht, habe es angepasst, ist im git.
Der gradient des Hintergrundes ist nun so definiert:
background: linear-gradient(to bottom right, var(--light3), var(--light1));
Damit folgt er der Farbdefinition von light1 und light3
Das ging noch nicht, habe es angepasst, ist im git.
D.h., ich muss nur die neue Version installieren?
Das ging noch nicht, habe es angepasst, ist im git.
Habe p4d neu installiert.
Schaut schon mal besser aus.
Danke fürs anpassen.
Aber es gibt schon noch ein paar Stellen, die man farblich optimieren sollte.
Melde mich dazu gleich nochmal.
Das ist mir zur Farbsteuerung noch aufgefallen:
1. stylesheet.css
Du verwendet den Parameter --neutral4: #a3a3a3; einmal als Farbe für Fonts und gleichzeitig an anderer Stelle als Farbe für den Hintergrund.
Als Farbe für Fonts auf den Menüseiten bei "Daemon, WEB Interface, MQTT, Home Automation Interface, usw."
Als Farbe für Hintergrund bei den Buttons "Konfiguration, IO Setup, User, Alerts, usw."
Das ist supoptimal.
Die Fonts sollten dunkler sein.
Der Button-Hintergrund sollte aber nicht dunkler werden.
2. Untermenüs bei "Setup"
Folgende Untermenüs haben noch dunkle Hintergrundbereiche:
"Alerts, Baugruppen, Syslog, Database, Wifi"
3. Variable in "stylesheet-light.css"
Gib bitte mal folgender Variable diese Farbe:
--neutral3: #cccccc;
4. Variable in "base.css" bei "buttonOptions"
Bei buttonOptions ist background-color: #708090; definiert.
Die Farbe ist fix und kommt nicht aus der "stylesheet.css".
Dadurch auch keine Farbschema-Steuerung durch "stylesheet.css" möglich.
Vll. kannst Du das noch umbauen.
5. Variablen in "chart.js"
Kannst Du Farb-Variablen von der "stylesheet.css" an "chart.js" übergeben?
Dann könnte man auch hier Farbschemabhängig steuern.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!