Problem Admin- oder Influx-Adapter ?
-
@homoran sagte in Problem Admin- oder Influx-Adapter ?:
nutze influxdb nicht, aber so sollte das nicht aussehen.
Wenn deaktiviert soll da eine 0 stehen, und die Überschrift höherAlso das sieht bei jedem Datenpunkt so aus bei mir.
Habe das mal auf 0 geändert für den Datenpunkt und gespeichert aber der Effekt ist derselbe. VM Lief voll und nichts geht mehr. Da kann ich auch so viel Speicher geben wie ich will ist immer desgleichen und das ist nur für eine halbe Stunde !!!!
Irgendwas stimmt da nicht.@segway ich hab das so
bei mir ist allerdings in der Basiseinstellung history hinterlegt
umgestiegen von Proxmox auf Unraid
-
@homoran sagte in Problem Admin- oder Influx-Adapter ?:
nutze influxdb nicht, aber so sollte das nicht aussehen.
Wenn deaktiviert soll da eine 0 stehen, und die Überschrift höherAlso das sieht bei jedem Datenpunkt so aus bei mir.
Habe das mal auf 0 geändert für den Datenpunkt und gespeichert aber der Effekt ist derselbe. VM Lief voll und nichts geht mehr. Da kann ich auch so viel Speicher geben wie ich will ist immer desgleichen und das ist nur für eine halbe Stunde !!!!
Irgendwas stimmt da nicht.@segway sagte in Problem Admin- oder Influx-Adapter ?:
und das ist nur für eine halbe Stunde !!!!
So ist es leider nicht. Der Adapter macht im Hintergrund Abfragen über den gesamten Datenbestand (für das selektierte Measurement). Ich vermute, dass du dort so viel Daten drin hast, dass die InfluxDB die Segel streicht.
Hier kannst du mal schauen, wie viele Datensätze jeweils drin sind, ist natürlich dann fraglich, ob die DB das schafft:
from(bucket: "iobroker") |> range(start: -10y) |> filter(fn: (r) => r["_field"] == "value") |> count() |> group() |> keep(columns: ["_measurement", "_value"]) |> sort(columns: ["_value"], desc: true) |> rename(columns: {_value: "Anzahl"})NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+EMQX+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@segway sagte in Problem Admin- oder Influx-Adapter ?:
und das ist nur für eine halbe Stunde !!!!
So ist es leider nicht. Der Adapter macht im Hintergrund Abfragen über den gesamten Datenbestand (für das selektierte Measurement). Ich vermute, dass du dort so viel Daten drin hast, dass die InfluxDB die Segel streicht.
Hier kannst du mal schauen, wie viele Datensätze jeweils drin sind, ist natürlich dann fraglich, ob die DB das schafft:
from(bucket: "iobroker") |> range(start: -10y) |> filter(fn: (r) => r["_field"] == "value") |> count() |> group() |> keep(columns: ["_measurement", "_value"]) |> sort(columns: ["_value"], desc: true) |> rename(columns: {_value: "Anzahl"})@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
@segway sagte in Problem Admin- oder Influx-Adapter ?:
und das ist nur für eine halbe Stunde !!!!
So ist es leider nicht. Der Adapter macht im Hintergrund Abfragen über den gesamten Datenbestand (für das selektierte Measurement). Ich vermute, dass du dort so viel Daten drin hast, dass die InfluxDB die Segel streicht.
Hier kannst du mal schauen, wie viele Datensätze jeweils drin sind, ist natürlich dann fraglich, ob die DB das schafft:
Mhhh, natürlich habe ich sehr viele Daten drin, dafür soll die DB ja auch sein.
Warum fragt er den gesamten Datenbestand ab wenn ich nur einen Datenpunkt ausgewählt habe ? Das macht eher keine Sinn oder ?Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
@segway sagte in Problem Admin- oder Influx-Adapter ?:
und das ist nur für eine halbe Stunde !!!!
So ist es leider nicht. Der Adapter macht im Hintergrund Abfragen über den gesamten Datenbestand (für das selektierte Measurement). Ich vermute, dass du dort so viel Daten drin hast, dass die InfluxDB die Segel streicht.
Hier kannst du mal schauen, wie viele Datensätze jeweils drin sind, ist natürlich dann fraglich, ob die DB das schafft:
from(bucket: "iobroker") |> range(start: -10y) |> filter(fn: (r) => r["_field"] == "value") |> count() |> group() |> keep(columns: ["_measurement", "_value"]) |> sort(columns: ["_value"], desc: true) |> rename(columns: {_value: "Anzahl"})@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
from(bucket: "iobroker") |> range(start: -10y) |> filter(fn: (r) => r["_field"] == "value") |> count() |> group() |> keep(columns: ["_measurement", "_value"]) |> sort(columns: ["_value"], desc: true) |> rename(columns: {_value: "Anzahl"})Der Vollständigkeit halber hier das Ergebnis - aber bitte jetzt keine Diskussion darüber. Auf der Arbeit haben wir deutlich mehr an Daten:
Der Befehl wurde anstandslos in 96s abgearbeitet
Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
from(bucket: "iobroker") |> range(start: -10y) |> filter(fn: (r) => r["_field"] == "value") |> count() |> group() |> keep(columns: ["_measurement", "_value"]) |> sort(columns: ["_value"], desc: true) |> rename(columns: {_value: "Anzahl"})Der Vollständigkeit halber hier das Ergebnis - aber bitte jetzt keine Diskussion darüber. Auf der Arbeit haben wir deutlich mehr an Daten:
Der Befehl wurde anstandslos in 96s abgearbeitet
-
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
@segway sagte in Problem Admin- oder Influx-Adapter ?:
und das ist nur für eine halbe Stunde !!!!
So ist es leider nicht. Der Adapter macht im Hintergrund Abfragen über den gesamten Datenbestand (für das selektierte Measurement). Ich vermute, dass du dort so viel Daten drin hast, dass die InfluxDB die Segel streicht.
Hier kannst du mal schauen, wie viele Datensätze jeweils drin sind, ist natürlich dann fraglich, ob die DB das schafft:
Mhhh, natürlich habe ich sehr viele Daten drin, dafür soll die DB ja auch sein.
Warum fragt er den gesamten Datenbestand ab wenn ich nur einen Datenpunkt ausgewählt habe ? Das macht eher keine Sinn oder ?@segway sagte in Problem Admin- oder Influx-Adapter ?:
Warum fragt er den gesamten Datenbestand ab wenn ich nur einen Datenpunkt ausgewählt habe ? Das macht eher keine Sinn oder ?
Nein, ich hatte ja geschrieben, dass "nur das selektierte Measurement" / Datenpunkt abgefragt wird, dieses aber ab 1999. Das reicht aber offensichtlich bei deinen Datenmengen schon aus.
Unbhängig davon sind die Abfragen im Hintergrund wohl optimierungsbedürftig. Habe das gerade mal getestet. Wenn man auf Verlaufsdaten klickt, werden im Hintergrund acht Abfragen mit unterschiedlichen Zeiträumen abgefeuert.
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+EMQX+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
from(bucket: "iobroker") |> range(start: -10y) |> filter(fn: (r) => r["_field"] == "value") |> count() |> group() |> keep(columns: ["_measurement", "_value"]) |> sort(columns: ["_value"], desc: true) |> rename(columns: {_value: "Anzahl"})Der Vollständigkeit halber hier das Ergebnis - aber bitte jetzt keine Diskussion darüber. Auf der Arbeit haben wir deutlich mehr an Daten:
Der Befehl wurde anstandslos in 96s abgearbeitet
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Der Vollständigkeit halber hier das Ergebnis - aber bitte jetzt keine Diskussion darüber.
Kannst du mal auf
schalten? Gibt es da noch mehr als 12 Mio Datensätze?
-
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Warum fragt er den gesamten Datenbestand ab wenn ich nur einen Datenpunkt ausgewählt habe ? Das macht eher keine Sinn oder ?
Nein, ich hatte ja geschrieben, dass "nur das selektierte Measurement" / Datenpunkt abgefragt wird, dieses aber ab 1999. Das reicht aber offensichtlich bei deinen Datenmengen schon aus.
Unbhängig davon sind die Abfragen im Hintergrund wohl optimierungsbedürftig. Habe das gerade mal getestet. Wenn man auf Verlaufsdaten klickt, werden im Hintergrund acht Abfragen mit unterschiedlichen Zeiträumen abgefeuert.
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
Unbhängig davon sind die Abfragen im Hintergrund wohl optimierungsbedürftig. Habe das gerade mal getestet. Wenn man auf Verlaufsdaten klickt, werden im Hintergrund acht Abfragen mit unterschiedlichen Zeiträumen abgefeuert.
Das ist ja schonmal was. Aber erklärt das mein beschriebenes verhalten ?
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
Kannst du mal auf
schalten? Gibt es da noch mehr als 12 Mio Datensätze?Sind wohl ähnlich:
Hier sieht man noch die Influx VM, wie sie ihre Arbeit verrichtet für die 3 Abfragen von mir:
Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
Unbhängig davon sind die Abfragen im Hintergrund wohl optimierungsbedürftig. Habe das gerade mal getestet. Wenn man auf Verlaufsdaten klickt, werden im Hintergrund acht Abfragen mit unterschiedlichen Zeiträumen abgefeuert.
Das ist ja schonmal was. Aber erklärt das mein beschriebenes verhalten ?
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
Kannst du mal auf
schalten? Gibt es da noch mehr als 12 Mio Datensätze?Sind wohl ähnlich:
Hier sieht man noch die Influx VM, wie sie ihre Arbeit verrichtet für die 3 Abfragen von mir:
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Das ist ja schonmal was. Aber erklärt das mein beschriebenes verhalten ?
Ich finde das schon ziemlich plausibel. Die acht Queries werden ja praktisch zeitgleich abgesetzt. D.h. acht mal wird da parallel über (teilweise) 12 Mio Datensätze gerauscht. Da darf CPU und RAM aus meiner Sicht schon mal an Grenzen geraten.
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+EMQX+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Das ist ja schonmal was. Aber erklärt das mein beschriebenes verhalten ?
Ich finde das schon ziemlich plausibel. Die acht Queries werden ja praktisch zeitgleich abgesetzt. D.h. acht mal wird da parallel über (teilweise) 12 Mio Datensätze gerauscht. Da darf CPU und RAM aus meiner Sicht schon mal an Grenzen geraten.
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Das ist ja schonmal was. Aber erklärt das mein beschriebenes verhalten ?
Ich finde das schon ziemlich plausibel. Die acht Queries werden ja praktisch zeitgleich abgesetzt. D.h. acht mal wird da parallel über (teilweise) 12 Mio Datensätze gerauscht. Da darf CPU und RAM aus meiner Sicht schon mal an Grenzen geraten.
Also ein Bug ? Soll ich ein Issue aufmachen ?
Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Das ist ja schonmal was. Aber erklärt das mein beschriebenes verhalten ?
Ich finde das schon ziemlich plausibel. Die acht Queries werden ja praktisch zeitgleich abgesetzt. D.h. acht mal wird da parallel über (teilweise) 12 Mio Datensätze gerauscht. Da darf CPU und RAM aus meiner Sicht schon mal an Grenzen geraten.
Also ein Bug ? Soll ich ein Issue aufmachen ?
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Also ein Bug ? Soll ich ein Issue aufmachen ?
Als Bug würde ich es nicht unbedingt bezeichnen. Hier treffen nicht optimierte Abfragen auf, ähm..., nicht optimierte Daten.
Aber da ich die Queries sowieso gerade parat habe, kann ich das auch machen.
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+EMQX+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Also ein Bug ? Soll ich ein Issue aufmachen ?
Als Bug würde ich es nicht unbedingt bezeichnen. Hier treffen nicht optimierte Abfragen auf, ähm..., nicht optimierte Daten.
Aber da ich die Queries sowieso gerade parat habe, kann ich das auch machen.
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
Als Bug würde ich es nicht unbedingt bezeichnen. Hier treffen nicht optimierte Abfragen auf, ähm..., nicht optimierte Daten.
sehr schön ausgedrückt
Aber da ich die Queries sowieso gerade parat habe, kann ich das auch machen.
Alles klar danke. Poste mir bitte den Issue dann subscribe ich den
Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
Unbhängig davon sind die Abfragen im Hintergrund wohl optimierungsbedürftig. Habe das gerade mal getestet. Wenn man auf Verlaufsdaten klickt, werden im Hintergrund acht Abfragen mit unterschiedlichen Zeiträumen abgefeuert.
Das ist ja schonmal was. Aber erklärt das mein beschriebenes verhalten ?
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
Kannst du mal auf
schalten? Gibt es da noch mehr als 12 Mio Datensätze?Sind wohl ähnlich:
Hier sieht man noch die Influx VM, wie sie ihre Arbeit verrichtet für die 3 Abfragen von mir:
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Hier sieht man noch die Influx VM, wie sie ihre Arbeit verrichtet für die 3 Abfragen von mir:
Das selbe Bild hatte ich vor kurzem und der influx adapter hatte keine Verbindung. Als ich mich über SSH in der influx VM einloggen wollte stand ganz oben OOM Kill. Obwohl der RAM verbrauch bei mir immer 880-890MB von 1GB hatte. Ich hab den RAM jetzt auf 1,5GB erhöht jetzt nutzt die VM ca. 970MB.
Icht würde testweise den RAM mal erhöhen, falls es das nicht war kann man es ja wieder rückgängig machen...
-
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Da kann ich auch so viel Speicher geben wie ich will ist immer desgleichen
-
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Hier sieht man noch die Influx VM, wie sie ihre Arbeit verrichtet für die 3 Abfragen von mir:
Das selbe Bild hatte ich vor kurzem und der influx adapter hatte keine Verbindung. Als ich mich über SSH in der influx VM einloggen wollte stand ganz oben OOM Kill. Obwohl der RAM verbrauch bei mir immer 880-890MB von 1GB hatte. Ich hab den RAM jetzt auf 1,5GB erhöht jetzt nutzt die VM ca. 970MB.
Icht würde testweise den RAM mal erhöhen, falls es das nicht war kann man es ja wieder rückgängig machen...
@saeft_2003 sagte in Problem Admin- oder Influx-Adapter ?:
Icht würde testweise den RAM mal erhöhen, falls es das nicht war kann man es ja wieder rückgängig machen...
Hab ich ja bereits. Effekt der gleiche :-(
(von 2 auf 4Gb .. aktuell 3Gb)@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Da kann ich auch so viel Speicher geben wie ich will ist immer desgleichen
korrekt :-)
-
@marc-berg sagte in Problem Admin- oder Influx-Adapter ?:
Als Bug würde ich es nicht unbedingt bezeichnen. Hier treffen nicht optimierte Abfragen auf, ähm..., nicht optimierte Daten.
sehr schön ausgedrückt
Aber da ich die Queries sowieso gerade parat habe, kann ich das auch machen.
Alles klar danke. Poste mir bitte den Issue dann subscribe ich den
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Poste mir bitte den Issue dann subscribe ich den
Es gibt noch ein Bug, der dein Problem zumindest mitverursacht:
https://github.com/ioBroker/ioBroker.influxdb/issues/372
Durch einen fehlenden Filter wird viel mehr selektiert als notwendig.
-
Hallo,
habe jetzt zum wiederholtem Mal festgestellt, dass wenn ich unterm Admin unter Objekte auf einen Datenpunkt gehe und dort unter Influx und dann Verlaufsdaten anzeigen möchte, dann ist Standardmässig 30 Mins eingestellt aber wenn ein Wert sich öfterändert kommt die Eieruhr und nichts geht mehr :-(
es kommen sogar auf einmal lauter Fehler im Log:
influxdb.0 2024-01-01 12:33:21.351 error getHistory: Error: 3 Error happened while processing 3 queries influxdb.0 2024-01-01 12:33:21.351 warn Error in query "from(bucket: "iobroker") |> range(start: 2024-01-01T11:33:03.089Z) |> filter(fn: (r) => r["_measurement"] == "sonoff.0.DVES_2F4527.ENERGY_Factor") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns: ["_time"], desc: false) |> limit(n: 1)": Error: connect ECONNREFUSED 192.168.40.99:8086 influxdb.0 2024-01-01 12:33:21.350 error getHistory: Error: 3 Error happened while processing 3 queries influxdb.0 2024-01-01 12:33:21.350 warn Error in query "from(bucket: "iobroker") |> range(start: 2024-01-01T11:33:03.100Z) |> filter(fn: (r) => r["_measurement"] == "sonoff.0.DVES_2F4527.ENERGY_Current") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns: ["_time"], desc: false) |> limit(n: 1)": Error: connect ECONNREFUSED 192.168.40.99:8086 influxdb.0 2024-01-01 12:33:21.347 warn Error in query "from(bucket: "iobroker") |> range(start: 2023-12-31T11:00:00.000Z, stop: 2024-01-01T11:33:03.088Z) |> filter(fn: (r) => r["_measurement"] == "sonoff.0.DVES_2F4527.ENERGY_Factor") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)": Error: connect ECONNREFUSED 192.168.40.99:8086 influxdb.0 2024-01-01 12:33:21.346 warn Error in query "from(bucket: "iobroker") |> range(start: 2023-12-31T11:00:00.000Z, stop: 2024-01-01T11:33:03.099Z) |> filter(fn: (r) => r["_measurement"] == "sonoff.0.DVES_2F4527.ENERGY_Current") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> sort(columns:["_time"], desc: false)": Error: connect ECONNREFUSED 192.168.40.99:8086 influxdb.0 2024-01-01 12:33:21.344 error Error during ping: Error: read ECONNRESET. Attempting reconnect. influxdb.0 2024-01-01 12:33:21.342 warn Error in query "from(bucket: "iobroker") |> range(start: 2021-12-31T11:00:00.000Z, stop: 2023-12-31T10:59:59.999Z) |> filter(fn: (r) => r["_measurement"] == "sonoff.0.DVES_2F4527.ENERGY_Factor") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns: ["_time"], desc: true) |> limit(n: 1)": Error: socket hang up influxdb.0 2024-01-01 12:33:21.339 warn Error in query "from(bucket: "iobroker") |> range(start: 2021-12-31T11:00:00.000Z, stop: 2023-12-31T10:59:59.999Z) |> filter(fn: (r) => r["_measurement"] == "sonoff.0.DVES_2F4527.ENERGY_Current") |> pivot(rowKey:["_time"], columnKey: ["_field"], valueColumn: "_value") |> group() |> sort(columns: ["_time"], desc: true) |> limit(n: 1)": Error: socket hang upManchmal hängt der Adapter sich auf und wird gelb und der Proxmoxcontainer hat 100% Auslastung und 100% Raum-verbrauch.
Nach Neustart des Containers ist wieder alles gut.Nehme ich Werte die nicht so viele Datenpunkte haben geht es einwandfrei
Wo liegt das Problem ?
(Falls noch Infos benötigt werden bitte melden)Ergänzung:
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Manchmal hängt der Adapter sich auf und wird gelb und der Proxmoxcontainer hat 100% Auslastung und 100% Raum-verbrauch.
Nach Neustart des Containers ist wieder alles gut.Ja, das habe ich auch ab und an.
Ich fange das dann mit einem Blockly-Skript ab und starte den LXC einfach neu, danach läuft's wieder eine gute Zeit weiter. Es ist wohl die InfluxDb, die zu diesem Zeitpunkt RAM und CPU-Leistung frisst.
Die Ursache kenne ich (noch) nicht.
Heute z. B. um 08:30 Uhr
Proxmox und HA - dank KI/AI endlich "blocklyfrei"
-
@segway sagte in Problem Admin- oder Influx-Adapter ?:
Manchmal hängt der Adapter sich auf und wird gelb und der Proxmoxcontainer hat 100% Auslastung und 100% Raum-verbrauch.
Nach Neustart des Containers ist wieder alles gut.Ja, das habe ich auch ab und an.
Ich fange das dann mit einem Blockly-Skript ab und starte den LXC einfach neu, danach läuft's wieder eine gute Zeit weiter. Es ist wohl die InfluxDb, die zu diesem Zeitpunkt RAM und CPU-Leistung frisst.
Die Ursache kenne ich (noch) nicht.
Heute z. B. um 08:30 Uhr
@meister-mopper sagte in Problem Admin- oder Influx-Adapter ?:
Die Ursache kenne ich (noch) nicht.
Die InfluxDB reorganisiert sich ja regelmäßig und schreibt die Datenfiles neu. Das ist mit reichlich RAM Verbrauch verbunden. Du könntest versuchen an ein paar Parametern zu drehen, z.B. diese hier:
https://docs.influxdata.com/influxdb/v2/reference/config-options/#storage-max-concurrent-compactions
https://docs.influxdata.com/influxdb/v2/reference/config-options/#storage-max-index-log-file-size
https://docs.influxdata.com/influxdb/v2/reference/config-options/#storage-series-file-max-concurrent-snapshot-compactions
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden410
Online32.8k
Benutzer82.8k
Themen1.3m
Beiträge