Größe der Queue?

[Tinker232]

Hallo zusammen,

mein Datenlogger speichert seine Sensordaten zunächst in eine Queue zwischen. Sobald die Queue voll ist wird dann auf den USB-Stick geschrieben oder bei einer exception (falls USB-Stick abgezogen werden sollte oder oder ) die Messung abgebrochen.
Ich gehe mal davon aus, das man jede 2s ein Messwert bekommt, bei ingesamt 3 Sensoren.

Gibt es irgendwelche Anhaltspunkte nachdem man die Queue dimensionieren sollte?

Wenn ich die Queue zu groß mache und relativ wenige Daten anfallen wird eben auch erst spät gemerkt, dass es einen Fehler beim Schreiben gibt. Andernfalls möchte ich auch gerne im Falle eines Fehlers nicht zuviele Daten verlieren wenn sie zu groß ist.
Ich hoffe ihr versteht was ich meine und habt eventuell ein paar Tips?!
LG tina

[__deets__]

Bei einer so geringen Datenrate verstehe ich nicht, warum due ueberhaupt wartest zu schreiben. Wichtiger als da eine Queue zwischen zu schalten waere der Versuch, das wegschreiben so sicher gegen Stromausfall wie moeglich zu machen. Gerade gestern haben wir einige Strategien dazu hier besprochen. Du koenntest zB eine sqlite Datenbank verwenden. Die sollte da relativ robust sein.

[Tinker232]

Ich habe das mit einer einzigen Queue gelöst, weil ich Zugriffskonflite der einzelnen Sensoren (Threads) vermeiden möchte.
So schreibt jeder Sensor einfach in die Queue und ab einer gewissen Zeit wird eben diese geschrieben, so ist der Schreibprozess ganz unabhängig vom eigentlichen Leseprozess der Sensoren.
Es funktioniert auch alles wunderbar soweit. Ich möchte es jetzt nicht wieder umbauen, dazu fehlt mir die Zeit

Das Wegschreiben der Queue ist ja bei mir so gelöst, dass es jeweils dann schreibt sobald diese voll ist. Die Schreibintervalle sind also abhängig von Anzahl der Sensoren, dem Zeitinverall der Abfrage und der Größe der Queue.

Falls es jemanden interessiert, ich hab jetzt mal gerechnet, oder es zumindest versucht:
Bei drei Sensoren mit jeweils 2s / 10s / 60s Intervallen und einer Größe der Queue von 300 Werten beträgt die Schreibrate ca. 8min, was bei einem Stromausfall absolut verträglich ist.
Wenn alle drei Sensoren jedoch nur jede Minute aufnehmen komme ich auf 100min Schreibrate, was bei einer Langzeitaufnahme von >10 Tagen auch absolut in Ordnung geht

[__blackjack__]

Der Vorschlag war nicht zu warten mit dem Schreiben sondern die Ereignisse sofort zu schreiben. Die Queue kann bzw. muss wegen der Threads ja bleiben. Die Änderungen wären kein umbauen, sondern eigentlich nur das weglassen von dem Code der für das warten zuständig ist bis genug Daten zusammen gekommen sind.

[noisefloor]

Hallo,

Plan B: Redis als Datenbank benutzen und die Daten von Redis asynchron im Hintergrund auf die Platte schreiben lassen. Das ist bei Redis in der Config einstellbar. Dann brauchst du dich gar nicht ums schreiben an sich kümmern.

Nachtrag: die Größe der Queue müsstest du dir selbst berechnen, basierend auf der a) Datenmenge pro Minute (oder was auch immer) und b) deiner Akzeptanz für Datenverlust.

Gruß, noisefloor

[kbr]

Meine Empfehlung: mache es, wie von __blackjack__ beschrieben: Der Hauptthread wartet, bis etwas in der Queue ist, und schreibt das dann sofort weg. Das ist bei deiner Datenrate kein Problem.

[Sirius3]

@Tinker232: Dir geht es ja scheinbar darum, dass der Zeitraum der nicht-geschriebenen Daten zu groß wird. Limitierend ist also nicht die Anzahl, sondern die Zeit. Wenn Du also nicht immer sofort schreiben willst, dann schreib alle Minute oder alle 5 Minuten alle Daten, die sich seither in der Queue gesammelt haben.

Zudem gilt wie meist, ein Code sagt mehr als 1000 Worte.