influxdb auf HDD/SSD/External SSD IOPS Beschränkungen

[Basti Liciouz]

Hallo zusammen,

folgende Herausforderung:
Bislang habe ich meine influxdb auf dem Raspi betrieben. Ohne externen Speicher, alles lief auf der SD-Karte und es gab keinerlei Probleme.
Nun habe ich mir vor einigen Monaten eine neue Synology NAS angeschafft, es handelt sich um die 224+.
RAM ist wie gekauft = 2GB, und 2*2TB HDD sind verbaut.

Ich habe daraufhin die influxdb vom Raspi auf die NAS in einen Container umgezogen, eigentlich um die Sicherung einfacher zu gestalten, da die NAS sowieso immer über Nacht in die (deutsche) Cloud gesichert wird.

Nun ist mir aufgefallen, dass seitdem die Zugriffszeiten stark verzögert sind und häufiger ins Timeout laufen.
Nach längerer Suche scheinen die HDD's das Bottleneck zu sein, Stichwort IOPS. Dies bestätigte sich in der Tat, wenn ich live den Ressourcenmonitor beobachtete, während ich wahlweise über Lovelace oder Grafana die Datenbank bemüht habe.

Anstelle nun "einfach" meine HDDs auf SSDs umzubauen, was ich ungerne möchte (Kosten/Zeitmangel) stellt sich mir die Frage, ob ich die gemounteten Ordner des influxdb Containers nicht auf eine kleine externe SSD am USB-Port der NAS betreiben könnte.

Aber: Ich suche seit einiger Zeit nach verlässlichen Informationen, ob nicht doch die HDDs diesen Plan wieder durchkreuzen (Zwischenspeicherung, etc. und somit Ausbremsung auf die IOPS der HDD anstelle direkte Nutzung der IOPS-Möglichkeiten der externen SSD).

Falls hier jemand zuverlässige Informationen hat, wäre ich sehr dankbar.
Ein Hinweis noch: Der Arbeitsspeicher selber läuft nicht voll. Und selbst wenn: Habe eh gerade 16GB RAM bestellt, dann gäbe es dort so oder so kein Bottleneck (mehr).

Danke und VG

[arteck]

@basti-liciouz hmm ulkig hör ich zum ersten mal dass eine Platte soooooooooooooooooooooooooooooooooooooooooo langsam ist dass es in Zugriff auf time out läuft.. ausser du machst eine Auswertung über grossen Zeitraum..aber selbst dann .. sollte der nicht auf timeout laufen

da würd ich eher mir die influxdb config anschauen

[OliverIO]

@basti-liciouz

Hm 2g ram, wenn ich höre Iobroker+influx+container
Je nachdem was auf der synology noch alles läuft ist der Prozessor mit swappen beschäftigt?
2gb ist relativ wenig?

Für influx 1 wurden schon 2-4gb angenommen
https://docs.influxdata.com/influxdb/v1/guides/hardware_sizing/#influxdb-oss-guidelines

Eine Datenbank hält relativ viel im ram

[Basti Liciouz]

@oliverio Ja, ist wirklich knapp bemessen von Synology...da haben sie wieder gespart. Der Speicher ist zu 75% ausgelastet, sieht eher gut aus auch während der Zugriffe. Aber sobald die 16GB Erweiterung da sind, kann ich sagen, ob es wirklich nicht am Speicher liegt.

Danke schonmal für den Hinweis.

[Basti Liciouz]

@oliverio

Was mir im Gegensatz zur Influx 1 bei der Influx 2 auffällt: Verdoppelung der IOPS.
Und das ist vmtl. genau das Problem aus meiner Sicht: Die Seagate Ironwolfs, welche verbaut sind, haben 292 IOPS im Maximum angegeben. Das korreliert nicht so wirklich mit 500 bzw 1000 IOPS gem. Spec der Influx.

[OliverIO]

@basti-liciouz

ich sehe schon, du hast dich an den iops festgebissen.
ich glaube nicht, das du im hobby bereich an irgendeine dieser grenzen stößt.
aber der prozessor muss schnell genug die daten aus dem ram über den bus an die festplatte übertragen.
wenn der aber gerade damit beschäftigt ist programmteile aus dem swap (was ja auh auf der ssd liegt) vom ram nach ssd oder umgekehrt zu schaufeln, dann verwirft er nach einer gewissen zeit die schreiboperation für die datenbank, da betriebssystemoperationen erst einmal wichtiger sind.

hol dir mehr speicher und dann bin ich mir ziemlich sicher, das sich das problem erledigt.

du kannst ja mal parallel wenn die fehler auftreten auf der konsole mit dem befehl top auf die auslastung schauen im vergleich system zu user vergleichen

[Basti Liciouz]

@oliverio
Da der RAM nie wirklich voll war, hatte ich den Fokus tatsächlich auf den IOPS. Mit dem gerade eben verbauten Riegel ist es nun deutlich schneller. Ich sehe immer noch teils 20% I/O wait auf der CPU, ist aber aus Nutzersicht verschmerzbar. Schneller geht bekanntlich immer.

[OliverIO]

@basti-liciouz

wenn der swap zu mehr wie 10% genutzt wird, ohne das man RAM intensive Prozesse aktuell verwendet, hat man mE immer RAM-Probleme.

Ideal ist, wenn der Swap zu 0% genutzt wird. swap ist immer langsam und bremst alles aus.

[Homoran]

@oliverio sagte in influxdb auf HDD/SSD/External SSD IOPS Beschränkungen:

wenn der swap zu mehr wie 10% genutzt wird

Deswegen setzen Spezialisten ja den SWAP auf mehrere GB

[OliverIO]

@basti-liciouz sagte in influxdb auf HDD/SSD/External SSD IOPS Beschränkungen:

20% I/O wait

https://www.thomaschristlieb.de/was-bedeutet-eigentlich-io-wait-wirklich/

dann ist deine festplatte aber gut beschäftigt oder wirklich grotten langsam.
evtl mal ein punkt da reinzuschauen. führst du den ständig querys auf deine datenbank aus?
evtl muss man die datenbank optimieren durch ergänzen von indizies.
wenn eine datenbank ständig full table scans machen muss, weil die suchkriterien nicht indiziert sind, dann wächst der IO-Wert auch
aber, kann auch an anderen kontinuierlichen lese und schreib operationen liegen.

hier mal ein paar tools zum analsysieren in der reihenfolge
welches device
welcher prozess

https://www.baeldung.com/linux/monitor-disk-io