NEWS
ioBroker Docker - InfluxDB Error bei hoher Disk I/O
-
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 -
@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
BerndDanke Bernd, hab ich eingestellt.
Du sag mal, wo genau in der Influx Doku hast du den denn gefunden? Wenn ich nach dem Parameter in Google suche, finde ich nicht wirklich was.[Edit]
Habs gefunden: https://docs.influxdata.com/influxdb/v2.7/reference/config-options/#storage-write-timeout -
Danke Bernd, hab ich eingestellt.
Du sag mal, wo genau in der Influx Doku hast du den denn gefunden? Wenn ich nach dem Parameter in Google suche, finde ich nicht wirklich was.[Edit]
Habs gefunden: https://docs.influxdata.com/influxdb/v2.7/reference/config-options/#storage-write-timeout@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Danke Bernd, hab ich eingestellt.
Du sag mal, wo genau in der Influx Doku hast du den denn gefunden? Wenn ich nach dem Parameter in Google suche, finde ich nicht wirklich was.Moin,
ich stöber immer beim Hersteller selbst :)
Das ist die Einstiegsseite https://docs.influxdata.com/influxdb/v2.7/# und dann entweder in der Suche oben links.
Das ist die Seite mit den Optionen https://docs.influxdata.com/influxdb/v2.7/reference/config-options/#VG
Bernd -
kleines Zwischenfazit: heute Nacht war alles gut, kein Anstieg zu verzeichnen
Mal schauen wie sich das die nächsten Tage verhält -
So, ich hatte zwar zwischendrin (irgendwann mal im Laufe des Tages) wieder einen Vorfall, aber bis jetzt scheint es Nachts nach der Sicherung immer zu funktionieren.
@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
So, ich hatte zwar zwischendrin (irgendwann mal im Laufe des Tages) wieder einen Vorfall,
Moin,
erst einmal schön, dass es bei Dir jetzt etwas ruhiger zugeht und alles so weit funktioniert.
Wenn es passieren solltest, Du mal schauen, was Du gerade gemacht hast, am/im System und/oder schauen, was da die DiskStation gerade gemacht hat, vielleicht lief da gerade ein aufwändiger Task.
VG
Bernd -
@glasfaser said in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Ich kenne deine Grundeinstellungen in der Influx Instanz nicht ,
du könntest versuchen die Schreibaktionen zu sammeln
sie werden dann zwischengespeichert und einmalig von Influx in der eingestellten Zeit versendet .
Nachteil , sollte etwas in der Zwischenspeicherung / Zeit passieren , sind die Daten weg .
Bedenke .. Hyper Backup braucht viel Leistung , habe daher die Zeiten ( mehere Regeln ) versetzt eingestellt
Danke für diesen Tipp. Ich bin in den letzten Wochen ebenfalls mit dem oben beschriebenen Problem konfrontiert worden.
Habe nun versuchsweise die Schreibaktionen zusammenfassen auf 5 gestellt. Der Fehler tritt nicht mehr auf. Nun habe ich es seit drei Tagen auf 2 eingestellt, ebenfalls keine Fehlermeldungen mehr bis jetzt. -
@glasfaser said in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
Ich kenne deine Grundeinstellungen in der Influx Instanz nicht ,
du könntest versuchen die Schreibaktionen zu sammelnsie werden dann zwischengespeichert und einmalig von Influx in der eingestellten Zeit versendet .
Nachteil , sollte etwas in der Zwischenspeicherung / Zeit passieren , sind die Daten weg .
Bedenke .. Hyper Backup braucht viel Leistung , habe daher die Zeiten ( mehere Regeln ) versetzt eingestellt
Danke für diesen Tipp. Ich bin in den letzten Wochen ebenfalls mit dem oben beschriebenen Problem konfrontiert worden.
Habe nun versuchsweise die Schreibaktionen zusammenfassen auf 5 gestellt. Der Fehler tritt nicht mehr auf. Nun habe ich es seit drei Tagen auf 2 eingestellt, ebenfalls keine Fehlermeldungen mehr bis jetzt.
Support us
815
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge