NEWS
ioBroker Docker - InfluxDB Error bei hoher Disk I/O
-
@dp20eic
Ok, ich gucke morgen früh. -
Moin zusammen,
heute keine Fehler in ioBroker. Aber den Peak um 3 Uhr sieht man trotzdem schön:
Grüße
Henri -
Moin,
im ersten Bild, der Peak ist der
read IO
da geht dann wohl die Sicherung desiobrokers
los.
Das sieht aber erst einmal alles nicht so dramatisch aus.VG
Bernd -
@dp20eic sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:
im ersten Bild, der Peak ist der
read IO
da geht dann wohl die Sicherung desiobrokers
los.Nein, die Sicherung des ioBroker ist um 01:24 Uhr. Das Hyper Backup der Daten auf dem NAS inkl. der Dockerfiles (also alle gemounteten Ordner) läuft um 03:00 Uhr. Und zu diesem Zeitpunkt traten bisher immer die Probleme auf.
-
@palm_maniac
bei mir ebenfalls unter Proxmox , ich starte den InfluxDB Adapter aktuell kurz nach dem Backup neu. -
Moin,
hast Du schon einmal das
Hyper Backup
ausgeschaltet, bzw. auf nur am Wochenende gestellt. Ich habe keine Ahnung vomHyper backup
und wie das Arbeitet.@thoml
Hast Du auch dasHyperBackup
am laufen?VG
Bernd -
@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 -
@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)
-
-
@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 Backup
daran schuld ist, dann kann manSynology
darauf 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 -
Moin,
im Bild mit dem Storage IO ist die blaue Kurve der
Read
Anteil, 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
HyperBackup
zusammen 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
-
Hab heute den automatischen Neustart um 03:10 Uhr täglich eingestellt.
-
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:latest
und 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
-
@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.
-
@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: