ioBroker Docker - InfluxDB Error bei hoher Disk I/O

[A Former User]

@hennerich sagte in ioBroker Docker - InfluxDB Error bei hoher Disk I/O:

@dp20eic

Ok, Dashboard läuft. Der ausschlaggebende Punkt war "localhost"!
Jetzt muss ich nur überlegen, wohin ich schauen muss wenn es wieder geknallt hat.

Moin,

also heute mal etwas Trouble in einer influxdb gehabt

Da sollte wenn Du wieder Write errors bekommst, sollte man das Object write io erkennen.

VG
Bernd

[hennerich]

@dp20eic
Ok, ich gucke morgen früh.

[hennerich]

Moin zusammen,

heute keine Fehler in ioBroker. Aber den Peak um 3 Uhr sieht man trotzdem schön:

Grüße
Henri

[A Former User]

@hennerich

Moin,

im ersten Bild, der Peak ist der read IO da geht dann wohl die Sicherung des iobrokers los.
Das sieht aber erst einmal alles nicht so dramatisch aus.

VG
Bernd

[hennerich]

@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 des iobrokers 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.

[thoml]

@palm_maniac
bei mir ebenfalls unter Proxmox , ich starte den InfluxDB Adapter aktuell kurz nach dem Backup neu.

[A Former User]

@hennerich

Moin,

hast Du schon einmal das Hyper Backup ausgeschaltet, bzw. auf nur am Wochenende gestellt. Ich habe keine Ahnung vom Hyper backup und wie das Arbeitet.

@thoml
Hast Du auch das HyperBackup am laufen?

VG
Bernd

[thoml]

@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.

[A Former User]

@thoml

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  - warn: influxdb.0 (9897) Point could not be written to database: iobdata
2023-02-07 03:03:23.696  - warn: 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

[thoml]

@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)

[A Former User]

@thoml

Moin,
bei mir sieht die Sicherung der Container so aus

VG
Bernd

[hennerich]

@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?

[A Former User]

@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 man Synology darauf aufmerksam machen denn die verkaufen das ja immerhin und ist dann ja kein Fehler im/bei iobroker / influxDB.
Sich nach einer anderen Lösung zur Sicherung der Daten und Docker Container umschauen.

Zum Thema, neustart Adapter.

1. Experten Modus einschalten
   

2. Adapter öffnen und Stift auswählen
   

3. Cron für Restart einrichten
   

VG
Bernd

[hennerich]

@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

[A Former User]

@hennerich

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älligkeiten

Wenn 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

[hennerich]

@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älligkeiten

Kann ich denn bis auf Systemsteuerung/Info/Speicher noch mehr testen? Denn das sieht gut aus:

Danke für deine Ideen Bernd

[hennerich]

Hab heute den automatischen Neustart um 03:10 Uhr täglich eingestellt.

[hennerich]

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-875697382

Mein 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_DELAY

Aber 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?

cbarzu created this issue in influxdata/influxdb

closed failed to store statistics: timeout 1.2.0 #8036

[Marc Berg]

@hennerich

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]

@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.