NEWS
ioBroker Docker - InfluxDB Error bei hoher Disk I/O
-
@dp20eic
Proxmox macht nachts um 1 jeden Tag ein Backup bei mir.
Das ganze läuft auf einem MiniPc, ioBroker läuft in einer VM und influxDB in einem Container.Moin,
ok, stehe auf dem schlauch.hier hat der TE das Problem, das zu einer bestimmten Uhrzeit etwas Fehler schmeißt, im ersten Post
Auszug:2023-02-07 03:03:23.690 - [33mwarn[39m: influxdb.0 (9897) Point could not be written to database: iobdata 2023-02-07 03:03:23.696 - [33mwarn[39m: influxdb.0 (9897) Error on writePoint("{"value":394,"time":"2023-02-07T02:03:03.022Z","from":"system.adapter.javascript.0","q":0,"ack":true}): HttpError: unexpected error writing points to database: timeout / "unexpected error writing points to database: timeout""Ich mache auch mittels PBS (Proxmox Backup Server) backups und muss meine LXC Container nicht neu starten.
Hast Du das gleiche Problem, bekomme gerade zu Deiner Aussagen den Bogen nicht gespannt.
VG
Bernd -
Moin,
ok, stehe auf dem schlauch.hier hat der TE das Problem, das zu einer bestimmten Uhrzeit etwas Fehler schmeißt, im ersten Post
Auszug:2023-02-07 03:03:23.690 - [33mwarn[39m: influxdb.0 (9897) Point could not be written to database: iobdata 2023-02-07 03:03:23.696 - [33mwarn[39m: influxdb.0 (9897) Error on writePoint("{"value":394,"time":"2023-02-07T02:03:03.022Z","from":"system.adapter.javascript.0","q":0,"ack":true}): HttpError: unexpected error writing points to database: timeout / "unexpected error writing points to database: timeout""Ich mache auch mittels PBS (Proxmox Backup Server) backups und muss meine LXC Container nicht neu starten.
Hast Du das gleiche Problem, bekomme gerade zu Deiner Aussagen den Bogen nicht gespannt.
VG
Bernd@dp20eic
Ja genau, habe das selbe Problem.
Zeitgleich steigt dann das IO Delay stark an und mein Server load steigt auf das bis zu 8-Fache an. Starte ich den InfluxDB Adapter neu fängt sich alles wieder.Ich hab für heute Nacht das Backup einmal deaktiviert und schaue morgen früh einmal ob es wirklich daher kommt. (Zeitlich passt das aber)
-
@dp20eic
Ja genau, habe das selbe Problem.
Zeitgleich steigt dann das IO Delay stark an und mein Server load steigt auf das bis zu 8-Fache an. Starte ich den InfluxDB Adapter neu fängt sich alles wieder.Ich hab für heute Nacht das Backup einmal deaktiviert und schaue morgen früh einmal ob es wirklich daher kommt. (Zeitlich passt das aber)
-
@palm_maniac
bei mir ebenfalls unter Proxmox , ich starte den InfluxDB Adapter aktuell kurz nach dem Backup neu.@thoml sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
@palm_maniac
bei mir ebenfalls unter Proxmox , ich starte den InfluxDB Adapter aktuell kurz nach dem Backup neu.Das hatte ich ja auch vor, wusste nur nicht wie das geht. Und ja, das löst das Problem nicht, genauso wenig wie nur eine Sicherung in der Woche. Aber der Workaround würde erstmal für Entspannung sorgen. Zumal ich mit einer ev. Erkenntnis, dass die hohe Disk I/O dafür verantwortlich ist auch nichts weiter anfangen könnte. Denn was sollte ich denn dann ändern?
-
@thoml sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
@palm_maniac
bei mir ebenfalls unter Proxmox , ich starte den InfluxDB Adapter aktuell kurz nach dem Backup neu.Das hatte ich ja auch vor, wusste nur nicht wie das geht. Und ja, das löst das Problem nicht, genauso wenig wie nur eine Sicherung in der Woche. Aber der Workaround würde erstmal für Entspannung sorgen. Zumal ich mit einer ev. Erkenntnis, dass die hohe Disk I/O dafür verantwortlich ist auch nichts weiter anfangen könnte. Denn was sollte ich denn dann ändern?
@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Denn was sollte ich denn dann ändern?
Moin,
wenn es sich heraus stellt, das das
Hyper Backupdaran schuld ist, dann kann manSynologydarauf aufmerksam machen denn die verkaufen das ja immerhin und ist dann ja kein Fehler im/beiiobroker/influxDB.
Sich nach einer anderen Lösung zur Sicherung der Daten und Docker Container umschauen.Zum Thema, neustart Adapter.
-
Experten Modus einschalten
-
Adapter öffnen und Stift auswählen
-
Cron für Restart einrichten
VG
Bernd -
-
@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Denn was sollte ich denn dann ändern?
Moin,
wenn es sich heraus stellt, das das
Hyper Backupdaran schuld ist, dann kann manSynologydarauf aufmerksam machen denn die verkaufen das ja immerhin und ist dann ja kein Fehler im/beiiobroker/influxDB.
Sich nach einer anderen Lösung zur Sicherung der Daten und Docker Container umschauen.Zum Thema, neustart Adapter.
-
Experten Modus einschalten
-
Adapter öffnen und Stift auswählen
-
Cron für Restart einrichten
VG
Bernd@dp20eic
Moin zusammen,
die letzten 3 Tage gabs wieder um kurz nach 3 Uhr Probleme. So sah das Dashboard dazu immer aus:
und so, als ich heute den Adapter neu gestartet habe:
Hier noch mal der gesamte Verlauf sowie die anderen Graphen
Was mache ich jetzt mit diesen Informationen?
Danke
Henri -
-
@dp20eic
Moin zusammen,
die letzten 3 Tage gabs wieder um kurz nach 3 Uhr Probleme. So sah das Dashboard dazu immer aus:
und so, als ich heute den Adapter neu gestartet habe:
Hier noch mal der gesamte Verlauf sowie die anderen Graphen
Was mache ich jetzt mit diesen Informationen?
Danke
HenriMoin,
im Bild mit dem Storage IO ist die blaue Kurve der
ReadAnteil, zu der Zeit hat etwas kräftig gelesen und das, was da am gewerkelt hat, brauchte Speicher.Kannst Du dort mehr Memory zuteilen?
Das andere, Read/Write IO haben auch immer etwas mit dem dazugehörigen Speichermedium zu tun, was nutzt Du da noch mal, HDD oder SSD?Gerade noch mal oben nachgelesen, Syno. DS220 ohne SSD und ohne SSD Cache.
Wie sehen denn die S.M.A.R.T Werte der verbauten Platten aus? Sind da evtl. schon AuffälligkeitenWenn es wirklich mit dem
HyperBackupzusammen hängt, diesmal ging es ja bis 9:30 Uhr, dann würde ich mich mal nach einer anderen Backuplösung umsehen.VG
Bernd -
Moin,
im Bild mit dem Storage IO ist die blaue Kurve der
ReadAnteil, zu der Zeit hat etwas kräftig gelesen und das, was da am gewerkelt hat, brauchte Speicher.Kannst Du dort mehr Memory zuteilen?
Das andere, Read/Write IO haben auch immer etwas mit dem dazugehörigen Speichermedium zu tun, was nutzt Du da noch mal, HDD oder SSD?Gerade noch mal oben nachgelesen, Syno. DS220 ohne SSD und ohne SSD Cache.
Wie sehen denn die S.M.A.R.T Werte der verbauten Platten aus? Sind da evtl. schon AuffälligkeitenWenn es wirklich mit dem
HyperBackupzusammen hängt, diesmal ging es ja bis 9:30 Uhr, dann würde ich mich mal nach einer anderen Backuplösung umsehen.VG
Bernd@dp20eic sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Kannst Du dort mehr Memory zuteilen?
Hmm, wenn ich weiß wie das geht? Hatte die DS220+ damals mit einem Upgrade auf 10GB RAM ausgestattet, damit die Docker Container genügend Ressourcen bekommen.
Das andere, Read/Write IO haben auch immer etwas mit dem dazugehörigen Speichermedium zu tun, was nutzt Du da noch mal, HDD oder SSD?
Ich hab WD Red HDDs drin, die ich schon in meinem alten NAS im Einsatz hatte. Damals hatte ich die WD Green Serie verbaut, die nach paar Jahren kaputt gegangen sind und mir Mega Probleme gemacht haben. Mit der Serverversion bin ich dann gut gefahren.
Gerade noch mal oben nachgelesen, Syno. DS220 ohne SSD und ohne SSD Cache.
Wie sehen denn die S.M.A.R.T Werte der verbauten Platten aus? Sind da evtl. schon AuffälligkeitenKann ich denn bis auf Systemsteuerung/Info/Speicher noch mehr testen? Denn das sieht gut aus:
Danke für deine Ideen Bernd
-
@dp20eic sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Kannst Du dort mehr Memory zuteilen?
Hmm, wenn ich weiß wie das geht? Hatte die DS220+ damals mit einem Upgrade auf 10GB RAM ausgestattet, damit die Docker Container genügend Ressourcen bekommen.
Das andere, Read/Write IO haben auch immer etwas mit dem dazugehörigen Speichermedium zu tun, was nutzt Du da noch mal, HDD oder SSD?
Ich hab WD Red HDDs drin, die ich schon in meinem alten NAS im Einsatz hatte. Damals hatte ich die WD Green Serie verbaut, die nach paar Jahren kaputt gegangen sind und mir Mega Probleme gemacht haben. Mit der Serverversion bin ich dann gut gefahren.
Gerade noch mal oben nachgelesen, Syno. DS220 ohne SSD und ohne SSD Cache.
Wie sehen denn die S.M.A.R.T Werte der verbauten Platten aus? Sind da evtl. schon AuffälligkeitenKann ich denn bis auf Systemsteuerung/Info/Speicher noch mehr testen? Denn das sieht gut aus:
Danke für deine Ideen Bernd
-
Hallo Leute,
ich muss das Thema noch mal aufmachen, weil sich die Situation mit dem Reboot signifikant verbessert hat, trotzdem ab und an aus unerfindlichen Gründen das Log explodiert.
Hier hatte ich einen Ansatz gefunden, den ich gerne ausprobieren würde:
https://github.com/influxdata/influxdb/issues/8036#issuecomment-875697382Mein Problem ist jetzt, dass ich die entsprechende Variable im Docker Container mitgeben muss, da sonst der Default Wert greift.
Das habe ich mal so versucht und zwar mit der Deklaration wie hier beschrieben:
https://docs.influxdata.com/influxdb/v2.0/reference/config-options/docker run -d --name=influxdb \ -p 8086:8086 \ -v /volume1/docker/influxdb:/var/lib/influxdb \ -v /volume1/docker/influxdb/data2:/var/lib/influxdb2 \ -v /volume1/docker/influxdb/config:/etc/influxdb2 \ -e INFLUXDB_DATA_WAL_FSYNC_DELAY=120 \ -e INFLUXDB_COORDINATOR_WRITE_TIMEOUT=30 \ influxdb:latestund anschließend auf der InfluxDB Console mal die Server Config ausgelesen:
root@ff56b05fc467:/# influx server-config { "assets-path": "", "bolt-path": "/var/lib/influxdb2/influxd.bolt", "e2e-testing": false, "engine-path": "/var/lib/influxdb2/engine", "feature-flags": null, "flux-log-enabled": false, "hardening-enabled": false, "http-bind-address": ":8086", "http-idle-timeout": 180000000000, "http-read-header-timeout": 10000000000, "http-read-timeout": 0, "http-write-timeout": 0, "influxql-max-select-buckets": 0, "influxql-max-select-point": 0, "influxql-max-select-series": 0, "instance-id": "", "log-level": "info", "metrics-disabled": false, "nats-max-payload-bytes": 0, "nats-port": 4222, "no-tasks": false, "pprof-disabled": false, "query-concurrency": 1024, "query-initial-memory-bytes": 0, "query-max-memory-bytes": 0, "query-memory-bytes": 0, "query-queue-size": 1024, "reporting-disabled": false, "secret-store": "bolt", "session-length": 60, "session-renew-disabled": false, "sqlite-path": "/var/lib/influxdb2/influxd.sqlite", "storage-cache-max-memory-size": 1073741824, "storage-cache-snapshot-memory-size": 26214400, "storage-cache-snapshot-write-cold-duration": "10m0s", "storage-compact-full-write-cold-duration": "4h0m0s", "storage-compact-throughput-burst": 50331648, "storage-max-concurrent-compactions": 0, "storage-max-index-log-file-size": 1048576, "storage-no-validate-field-size": false, "storage-retention-check-interval": "30m0s", "storage-series-file-max-concurrent-snapshot-compactions": 0, "storage-series-id-set-cache-size": 0, "storage-shard-precreator-advance-period": "30m0s", "storage-shard-precreator-check-interval": "10m0s", "storage-tsm-use-madv-willneed": false, "storage-validate-keys": false, "storage-wal-fsync-delay": "0s", "storage-wal-max-concurrent-writes": 0, "storage-wal-max-write-delay": 600000000000, "storage-write-timeout": 10000000000, "store": "disk", "testing-always-allow-setup": false, "tls-cert": "", "tls-key": "", "tls-min-version": "1.2", "tls-strict-ciphers": false, "tracing-type": "", "ui-disabled": false, "vault-addr": "", "vault-cacert": "", "vault-capath": "", "vault-client-cert": "", "vault-client-key": "", "vault-client-timeout": 0, "vault-max-retries": 0, "vault-skip-verify": false, "vault-tls-server-name": "", "vault-token": "" }Mein Problem ist jetzt, dass die Übergabe der Variablen scheinbar nicht greift, denn sonst müsste ja bei dem FSYNC nicht 0s stehen.
Dann hab ich irgendwo gelesen, dass mit Docker die Variable so übergeben werden muss:
INFLUXD_STORAGE_WAL_FSYNC_DELAYAber auch das funktioniert nicht.
Schaue ich denn auf der Container Konsole in die falschen Infos oder weiß jemand von euch, wie die richtige Variable heißt? -
Hallo Leute,
ich muss das Thema noch mal aufmachen, weil sich die Situation mit dem Reboot signifikant verbessert hat, trotzdem ab und an aus unerfindlichen Gründen das Log explodiert.
Hier hatte ich einen Ansatz gefunden, den ich gerne ausprobieren würde:
https://github.com/influxdata/influxdb/issues/8036#issuecomment-875697382Mein Problem ist jetzt, dass ich die entsprechende Variable im Docker Container mitgeben muss, da sonst der Default Wert greift.
Das habe ich mal so versucht und zwar mit der Deklaration wie hier beschrieben:
https://docs.influxdata.com/influxdb/v2.0/reference/config-options/docker run -d --name=influxdb \ -p 8086:8086 \ -v /volume1/docker/influxdb:/var/lib/influxdb \ -v /volume1/docker/influxdb/data2:/var/lib/influxdb2 \ -v /volume1/docker/influxdb/config:/etc/influxdb2 \ -e INFLUXDB_DATA_WAL_FSYNC_DELAY=120 \ -e INFLUXDB_COORDINATOR_WRITE_TIMEOUT=30 \ influxdb:latestund anschließend auf der InfluxDB Console mal die Server Config ausgelesen:
root@ff56b05fc467:/# influx server-config { "assets-path": "", "bolt-path": "/var/lib/influxdb2/influxd.bolt", "e2e-testing": false, "engine-path": "/var/lib/influxdb2/engine", "feature-flags": null, "flux-log-enabled": false, "hardening-enabled": false, "http-bind-address": ":8086", "http-idle-timeout": 180000000000, "http-read-header-timeout": 10000000000, "http-read-timeout": 0, "http-write-timeout": 0, "influxql-max-select-buckets": 0, "influxql-max-select-point": 0, "influxql-max-select-series": 0, "instance-id": "", "log-level": "info", "metrics-disabled": false, "nats-max-payload-bytes": 0, "nats-port": 4222, "no-tasks": false, "pprof-disabled": false, "query-concurrency": 1024, "query-initial-memory-bytes": 0, "query-max-memory-bytes": 0, "query-memory-bytes": 0, "query-queue-size": 1024, "reporting-disabled": false, "secret-store": "bolt", "session-length": 60, "session-renew-disabled": false, "sqlite-path": "/var/lib/influxdb2/influxd.sqlite", "storage-cache-max-memory-size": 1073741824, "storage-cache-snapshot-memory-size": 26214400, "storage-cache-snapshot-write-cold-duration": "10m0s", "storage-compact-full-write-cold-duration": "4h0m0s", "storage-compact-throughput-burst": 50331648, "storage-max-concurrent-compactions": 0, "storage-max-index-log-file-size": 1048576, "storage-no-validate-field-size": false, "storage-retention-check-interval": "30m0s", "storage-series-file-max-concurrent-snapshot-compactions": 0, "storage-series-id-set-cache-size": 0, "storage-shard-precreator-advance-period": "30m0s", "storage-shard-precreator-check-interval": "10m0s", "storage-tsm-use-madv-willneed": false, "storage-validate-keys": false, "storage-wal-fsync-delay": "0s", "storage-wal-max-concurrent-writes": 0, "storage-wal-max-write-delay": 600000000000, "storage-write-timeout": 10000000000, "store": "disk", "testing-always-allow-setup": false, "tls-cert": "", "tls-key": "", "tls-min-version": "1.2", "tls-strict-ciphers": false, "tracing-type": "", "ui-disabled": false, "vault-addr": "", "vault-cacert": "", "vault-capath": "", "vault-client-cert": "", "vault-client-key": "", "vault-client-timeout": 0, "vault-max-retries": 0, "vault-skip-verify": false, "vault-tls-server-name": "", "vault-token": "" }Mein Problem ist jetzt, dass die Übergabe der Variablen scheinbar nicht greift, denn sonst müsste ja bei dem FSYNC nicht 0s stehen.
Dann hab ich irgendwo gelesen, dass mit Docker die Variable so übergeben werden muss:
INFLUXD_STORAGE_WAL_FSYNC_DELAYAber auch das funktioniert nicht.
Schaue ich denn auf der Container Konsole in die falschen Infos oder weiß jemand von euch, wie die richtige Variable heißt?Ich nehme an, du willst die Variable auf 120ms stellen, dann muss du das auch so angeben:
INFLUXD_STORAGE_WAL_FSYNC_DELAY=120ms
-
Hallo Leute,
ich muss das Thema noch mal aufmachen, weil sich die Situation mit dem Reboot signifikant verbessert hat, trotzdem ab und an aus unerfindlichen Gründen das Log explodiert.
Hier hatte ich einen Ansatz gefunden, den ich gerne ausprobieren würde:
https://github.com/influxdata/influxdb/issues/8036#issuecomment-875697382Mein Problem ist jetzt, dass ich die entsprechende Variable im Docker Container mitgeben muss, da sonst der Default Wert greift.
Das habe ich mal so versucht und zwar mit der Deklaration wie hier beschrieben:
https://docs.influxdata.com/influxdb/v2.0/reference/config-options/docker run -d --name=influxdb \ -p 8086:8086 \ -v /volume1/docker/influxdb:/var/lib/influxdb \ -v /volume1/docker/influxdb/data2:/var/lib/influxdb2 \ -v /volume1/docker/influxdb/config:/etc/influxdb2 \ -e INFLUXDB_DATA_WAL_FSYNC_DELAY=120 \ -e INFLUXDB_COORDINATOR_WRITE_TIMEOUT=30 \ influxdb:latestund anschließend auf der InfluxDB Console mal die Server Config ausgelesen:
root@ff56b05fc467:/# influx server-config { "assets-path": "", "bolt-path": "/var/lib/influxdb2/influxd.bolt", "e2e-testing": false, "engine-path": "/var/lib/influxdb2/engine", "feature-flags": null, "flux-log-enabled": false, "hardening-enabled": false, "http-bind-address": ":8086", "http-idle-timeout": 180000000000, "http-read-header-timeout": 10000000000, "http-read-timeout": 0, "http-write-timeout": 0, "influxql-max-select-buckets": 0, "influxql-max-select-point": 0, "influxql-max-select-series": 0, "instance-id": "", "log-level": "info", "metrics-disabled": false, "nats-max-payload-bytes": 0, "nats-port": 4222, "no-tasks": false, "pprof-disabled": false, "query-concurrency": 1024, "query-initial-memory-bytes": 0, "query-max-memory-bytes": 0, "query-memory-bytes": 0, "query-queue-size": 1024, "reporting-disabled": false, "secret-store": "bolt", "session-length": 60, "session-renew-disabled": false, "sqlite-path": "/var/lib/influxdb2/influxd.sqlite", "storage-cache-max-memory-size": 1073741824, "storage-cache-snapshot-memory-size": 26214400, "storage-cache-snapshot-write-cold-duration": "10m0s", "storage-compact-full-write-cold-duration": "4h0m0s", "storage-compact-throughput-burst": 50331648, "storage-max-concurrent-compactions": 0, "storage-max-index-log-file-size": 1048576, "storage-no-validate-field-size": false, "storage-retention-check-interval": "30m0s", "storage-series-file-max-concurrent-snapshot-compactions": 0, "storage-series-id-set-cache-size": 0, "storage-shard-precreator-advance-period": "30m0s", "storage-shard-precreator-check-interval": "10m0s", "storage-tsm-use-madv-willneed": false, "storage-validate-keys": false, "storage-wal-fsync-delay": "0s", "storage-wal-max-concurrent-writes": 0, "storage-wal-max-write-delay": 600000000000, "storage-write-timeout": 10000000000, "store": "disk", "testing-always-allow-setup": false, "tls-cert": "", "tls-key": "", "tls-min-version": "1.2", "tls-strict-ciphers": false, "tracing-type": "", "ui-disabled": false, "vault-addr": "", "vault-cacert": "", "vault-capath": "", "vault-client-cert": "", "vault-client-key": "", "vault-client-timeout": 0, "vault-max-retries": 0, "vault-skip-verify": false, "vault-tls-server-name": "", "vault-token": "" }Mein Problem ist jetzt, dass die Übergabe der Variablen scheinbar nicht greift, denn sonst müsste ja bei dem FSYNC nicht 0s stehen.
Dann hab ich irgendwo gelesen, dass mit Docker die Variable so übergeben werden muss:
INFLUXD_STORAGE_WAL_FSYNC_DELAYAber auch das funktioniert nicht.
Schaue ich denn auf der Container Konsole in die falschen Infos oder weiß jemand von euch, wie die richtige Variable heißt?@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
INFLUXDB_COORDINATOR_WRITE_TIMEOUT
Diese Umgebungsvariable gibt es übrigens in der V2.x nicht mehr.
Hast du zu den Zeitpunkten, zu denen die Timeouts auftreten, Einträge im InfluxDB-Log, also auf der Docker-Console? In Abhängigkeit davon, ob zu diesem Zeitpunkt gerade ein Index geschrieben wird oder eine "Compaction" läuft, könnten unterschiedliche Anpassungen Sinn ergeben.
-
Ich nehme an, du willst die Variable auf 120ms stellen, dann muss du das auch so angeben:
INFLUXD_STORAGE_WAL_FSYNC_DELAY=120ms
@marc-berg sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Ich nehme an, du willst die Variable auf 120ms stellen, dann muss du das auch so angeben:
INFLUXD_STORAGE_WAL_FSYNC_DELAY=120ms
Hey Marc,
besten Dank für deine schnelle Rückmeldung.
Also gibt es die Variable aus meiner ersten Codebox (INFLUXDB_DATA_WAL_FSYNC_DELAY) nicht mehr oder es ist die falsche, richtig?
Und den Container hatte ich beim zweiten Versuch schon so mit Angabe der Zeit gestartet. Das wird mir angezeigt:
-
@marc-berg sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Ich nehme an, du willst die Variable auf 120ms stellen, dann muss du das auch so angeben:
INFLUXD_STORAGE_WAL_FSYNC_DELAY=120ms
Hey Marc,
besten Dank für deine schnelle Rückmeldung.
Also gibt es die Variable aus meiner ersten Codebox (INFLUXDB_DATA_WAL_FSYNC_DELAY) nicht mehr oder es ist die falsche, richtig?
Und den Container hatte ich beim zweiten Versuch schon so mit Angabe der Zeit gestartet. Das wird mir angezeigt:
@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Also gibt es die Variable aus meiner ersten Codebox (INFLUXDB_DATA_WAL_FSYNC_DELAY) nicht mehr oder es ist die falsche, richtig?
Die ist falsch. Die Variablen, die mit "INFLUXDB_" beginnen, sind meines Wissens nur für die 1.x gültig. Für die 2.x fangen alle mit "INFLUXD_" an
-
@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Also gibt es die Variable aus meiner ersten Codebox (INFLUXDB_DATA_WAL_FSYNC_DELAY) nicht mehr oder es ist die falsche, richtig?
Die ist falsch. Die Variablen, die mit "INFLUXDB_" beginnen, sind meines Wissens nur für die 1.x gültig. Für die 2.x fangen alle mit "INFLUXD_" an
@marc-berg sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Die ist falsch. Die Variablen, die mit "INFLUXDB_" beginnen, sind meines Wissens nur für die 1.x gültig. Für die 2.x fangen alle mit "INFLUXD_" an
Ok, ich hab jetzt die Variable noch mal neu gesetzt und die andere entfernt.
Beim Setzen der Variable hatte ich Anfangs nur 120 als Wert hinterlegt. Jetzt hab ich 120s genommen.
So sieht das jetzt aus:
Und wenn ich auf der Konsole nun die Konfiguration abrufe, steht in der Tat
"storage-wal-fsync-delay": "2m0s",Eventuell lag es an der nicht angegebenen Einheit.
@marc-berg sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Hast du zu den Zeitpunkten, zu denen die Timeouts auftreten, Einträge im InfluxDB-Log, also auf der Docker-Console? In Abhängigkeit davon, ob zu diesem Zeitpunkt gerade ein Index geschrieben wird oder eine "Compaction" läuft, könnten unterschiedliche Anpassungen Sinn ergeben.
Da hatte ich noch nie nachgeschaut. Hab das OS Dashboard installiert und immer wenn das Problem auftritt, sieht das so aus:
Jetzt gerade ist es wieder da und das ioBroker Log überschlägt sich mit Meldungen:
Wo genau muss ich nachschauen und worauf soll ich achten? -
@marc-berg sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Die ist falsch. Die Variablen, die mit "INFLUXDB_" beginnen, sind meines Wissens nur für die 1.x gültig. Für die 2.x fangen alle mit "INFLUXD_" an
Ok, ich hab jetzt die Variable noch mal neu gesetzt und die andere entfernt.
Beim Setzen der Variable hatte ich Anfangs nur 120 als Wert hinterlegt. Jetzt hab ich 120s genommen.
So sieht das jetzt aus:
Und wenn ich auf der Konsole nun die Konfiguration abrufe, steht in der Tat
"storage-wal-fsync-delay": "2m0s",Eventuell lag es an der nicht angegebenen Einheit.
@marc-berg sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Hast du zu den Zeitpunkten, zu denen die Timeouts auftreten, Einträge im InfluxDB-Log, also auf der Docker-Console? In Abhängigkeit davon, ob zu diesem Zeitpunkt gerade ein Index geschrieben wird oder eine "Compaction" läuft, könnten unterschiedliche Anpassungen Sinn ergeben.
Da hatte ich noch nie nachgeschaut. Hab das OS Dashboard installiert und immer wenn das Problem auftritt, sieht das so aus:
Jetzt gerade ist es wieder da und das ioBroker Log überschlägt sich mit Meldungen:
Wo genau muss ich nachschauen und worauf soll ich achten?@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Wo genau muss ich nachschauen und worauf soll ich achten?
Also bei mir (Docker+Portainer) kann ich auf die Container Logs schauen, da steht dann sowas drin:
ts=2023-05-26T20:26:23.033009Z lvl=info msg="Snapshot for path written" log_id=0i2HUNW0000 service=storage-engine engine=tsm1 op_name=tsm1_cache_snapshot path=/var/lib/influxdb2/engine/data/2b42fccaf44c370d/autogen/2747 duration=218.588ms ts=2023-05-26T20:26:23.033067Z lvl=info msg="Cache snapshot (end)" log_id=0i2HUNW0000 service=storage-engine engine=tsm1 op_name=tsm1_cache_snapshot op_event=end op_elapsed=218.661ms ts=2023-05-26T20:27:51.815523Z lvl=info msg="Retention policy deletion check (start)" log_id=0i2HUNW0000 service=retention op_name=retention_delete_check op_event=start ts=2023-05-26T20:27:51.816432Z lvl=info msg="Retention policy deletion check (end)" log_id=0i2HUNW0000 service=retention op_name=retention_delete_check op_event=end op_elapsed=0.947ms ts=2023-05-26T20:35:02.035245Z lvl=info msg="TSI log compaction (start)" log_id=0i2HUNW0000 service=storage-engine index=tsi tsi1_partition=1 op_name=tsi1_compact_log_file tsi1_log_file_id=3 op_event=start ts=2023-05-26T20:35:02.051768Z lvl=info msg="Log file compacted" log_id=0i2HUNW0000 service=storage-engine index=tsi tsi1_partition=1 op_name=tsi1_compact_log_file tsi1_log_file_id=3 elapsed=16ms bytes=1833 kb_per_sec=108 ts=2023-05-26T20:35:02.052216Z lvl=info msg="TSI log compaction (end)" log_id=0i2HUNW0000 service=storage-engine index=tsi tsi1_partition=1 op_name=tsi1_compact_log_file tsi1_log_file_id=3 op_event=end op_elapsed=17.005msKeine Ahnung, wie das bei dir aussieht. Die Idee war, dass man in diese Logs schaut, wenn die Timeouts auftreten, um zu sehen, was die DB in dieser Zeit macht.
Die 120 Sekunden finde ich ziemlich lang. Im Extremfall können dann 2min Daten verloren gehen. In den Konfigurationsbeispielen, die man so findet ist ja eher von Millisekunden die Rede.
-
@marc-berg sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Die ist falsch. Die Variablen, die mit "INFLUXDB_" beginnen, sind meines Wissens nur für die 1.x gültig. Für die 2.x fangen alle mit "INFLUXD_" an
Ok, ich hab jetzt die Variable noch mal neu gesetzt und die andere entfernt.
Beim Setzen der Variable hatte ich Anfangs nur 120 als Wert hinterlegt. Jetzt hab ich 120s genommen.
So sieht das jetzt aus:
Und wenn ich auf der Konsole nun die Konfiguration abrufe, steht in der Tat
"storage-wal-fsync-delay": "2m0s",Eventuell lag es an der nicht angegebenen Einheit.
@marc-berg sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Hast du zu den Zeitpunkten, zu denen die Timeouts auftreten, Einträge im InfluxDB-Log, also auf der Docker-Console? In Abhängigkeit davon, ob zu diesem Zeitpunkt gerade ein Index geschrieben wird oder eine "Compaction" läuft, könnten unterschiedliche Anpassungen Sinn ergeben.
Da hatte ich noch nie nachgeschaut. Hab das OS Dashboard installiert und immer wenn das Problem auftritt, sieht das so aus:
Jetzt gerade ist es wieder da und das ioBroker Log überschlägt sich mit Meldungen:
Wo genau muss ich nachschauen und worauf soll ich achten?@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Wo genau muss ich nachschauen und worauf soll ich achten?
Moin,
nur als Beispiel, da ich keine
influxDBauf meiner Syno als Docker habe, aber wenn Du auf der Syno Standard-Docker ohne Portainer nutzt, dann sollten die Logs hier einsehbar sein.Beispiel:
Du kannst auch mal im Ressourcenmonitor der Syno schauen, ob da etwas auffälliges zu sehen ist
VG
Bernd -
@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Wo genau muss ich nachschauen und worauf soll ich achten?
Moin,
nur als Beispiel, da ich keine
influxDBauf meiner Syno als Docker habe, aber wenn Du auf der Syno Standard-Docker ohne Portainer nutzt, dann sollten die Logs hier einsehbar sein.Beispiel:
Du kannst auch mal im Ressourcenmonitor der Syno schauen, ob da etwas auffälliges zu sehen ist
VG
BerndHey, danke für eure Ideen.
Ich hab auch Portainer und kann in die Logs schauen.
Nur hab ich davon keine Ahnung. Sowas steht da drin:
Seit gestern ist das ioBroker Log auf knapp 1GB angewachsen. Ich restarte jetzt den Adapter und lösche das Log.
Dann schauen wir mal, ob die 120s etwas gebracht haben. -
Update: als ich den Adapter neu gestartet habe, sind die Meldungen direkt wieder aufgetreten.
Ich kann nur vermuten, dass das an den 120s gelegen hat, denn nachdem ich den Wert zurück auf 0s (default) gestellt hatte, waren die Fehler wieder weg. -
Update: als ich den Adapter neu gestartet habe, sind die Meldungen direkt wieder aufgetreten.
Ich kann nur vermuten, dass das an den 120s gelegen hat, denn nachdem ich den Wert zurück auf 0s (default) gestellt hatte, waren die Fehler wieder weg.@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Update: als ich den Adapter neu gestartet habe, sind die Meldungen direkt wieder aufgetreten.
Ich kann nur vermuten, dass das an den 120s gelegen hat, denn nachdem ich den Wert zurück auf 0s (default) gestellt hatte, waren die Fehler wieder weg.Moin,
wie @Marc-Berg schon gesagt hat, 120s sind zu viel, denn als Standard ist 0, und in den Beispielen sind es
msalso wenn Du mit diesem Parameter spielen möchtest, dann eher immsBereich und nicht imsek.Bereich.Erklärung des Parameters https://docs.influxdata.com/influxdb/v2.7/reference/config-options/#influxd-flag-47
storage-wal-fsync-delay Duration a write will wait before fsyncing. A duration greater than 0 batches multiple fsync calls. This is useful for slower disks or when WAL write contention is present.Vielleicht ist das der bessere Wert, den Du anpassen kannst, Standard sind
10 sek.da kannst Du ja mal in Fünfer Schritten, die Zeit anpassen,INFLUXD_STORAGE_WRITE_TIMEOUTstorage-write-timeout Maximum amount of time the storage engine will process a write request before timing out.VG
Bernd
Support us
427
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge