UNSOLVED Datenpunkte werden nicht immer gesetzt

[antimon]

Systemdata	Bitte Ausfüllen
Hardwaresystem:	VMware auf Xeon E3-1230v3, 4vCPUs
Arbeitsspeicher:	4GB
Festplattenart:	HDD
Betriebssystem:	Ubuntu Server
Node-Version:	10.19.0
Nodejs-Version:	10.19.0
NPM-Version:	6.13.7
Installationsart:	Manuell
Image genutzt:	Nein
Ort/Name der Imagedatei:	Link

Ich habe das Phänomen, dass Datenpunkte nur mit einer Wahrscheinlichkeit von 95-98% gesetzt werden. Dazu habe ich folgenden Testcode geschrieben, und würde mich freuen, wenn diesen jemand in seiner Installation testen könnte um zu sehen ob es am Code liegt oder ob es ein allgemeines Problem ist.

Dazu wird folgender Datenpunkt benötigt:

{
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1581597835618,
  "common": {
    "name": "testvalue",
    "role": "",
    "type": "number",
    "desc": "Manuell erzeugt",
    "read": true,
    "write": true
  },
  "native": {},
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator",
    "state": 1636
  },
  "_id": "0_userdata.0.testvalue",
  "type": "state"
}

Folgender Code setzt den Datenpunkt und fragt ihn 100 ms später wieder ab. Ist der gesetzte Wert nicht gleich dem abgefragten, gibt es eine Warnung. Wenn ich den Code ausführe, habe ich mindestens 2, meistens aber auch 4-5 Warnungen, was bedeutet, dass der Datenpunkt fehlerhaft geschrieben wird.

function wait(time) {
    return new Promise(resolve => {
        setTimeout(() => {
            resolve();
        }, time);
    });
}

async function testState() {
    var test_id = "0_userdata.0.testvalue";
    var testval = 1;
    var matches = 0;

    for (var i = 0; i < 100; i++) {
        //log("Test #" + i);
        // Toggle
        testval = i + 1;
        setState(test_id, testval);
        await wait(100);
        if (getState(test_id).val == testval) {
            matches++;
        } else {
            log("No match!");
        }
    }
    log(matches + " Matches");
}

testState();

Tritt dieser Fehler bei euch auf? Wenn nein, habt Ihr eine Idee, woran es liegen könnte? Habe ich einen Fehler im Code? Wie kann ich am besten debuggen, an welcher Stelle der Fehler auftritt?

Ich habe schon alle Module reinstalliert - der Fehler tritt aber leider nach wie vor auf.

Viele Grüße,
Antimon

[paul53]

@antimon sagte:

fragt ihn 100 ms später wieder ab.

Das kann bei hoher Systemlast zu kurz sein.

[OliverIO]

@antimon
4 mal wiederholt. Keinen Ausfall
wurde immer beendet mit 100 matches
system ist ein Intel NUC 6cayh mit 8GB

[paul53]

@OliverIO sagte:

4 mal wiederholt. Keinen Ausfall
wurde immer beendet mit 100 matches

Dito.

[antimon]

Ah okay - erst mal vielen, vielen Dank für Eure Hilfe! Dann liegts jetzt eindeutig an meiner Installation, allerdings beunruhigt es mich etwas, dass die Fehler auftreten, ohne dass es offensichtliche Anzeichen dafür gibt (Fehlermeldungen etc.).

Eine hohe Systemlast würde ich ausschließen, die Maschine dümpelt vor sich hin und langweilt sich. Weder CPU noch RAM sind sonderlich ausgelastet, ausserdem habe ich zum Testen fast alle anderen Adapter deaktiviert und das System neu gestartet. Es macht keinen Unterschied.

Prinzipiell kann ich natürlich einfach neu installieren und ein Backup einspielen, aber ich würde gerne wissen wo der Fehler herkommt um ihn zukünftig vermeiden zu können - ausserdem könnte der Fehler evtl. mit dem Backup zurückeingespielt werden.

Habt Ihr evtl. ein paar Tips, wo ich bei der Fehlersuche ansetzen könnte?

[OliverIO]

ich habe keine Virtualisierung.
wie verhält es sich mit 150 und 200ms und mehr? ab wann ist es weg?
Ich weiß auch nicht ob socketio per tcp oder udp kommuniziert. bei tcp dürfte keine information wegen lag verloren gehen. evtl. wird es in der Software verworfen, weil jemand sagt es ist schon zu alt?
aber alles nur Vermutungen. ohne Fehlermeldung ist so etwas blöd.

[antimon]

@OliverIO Bei 200 ms ist es ab und zu (aber eher selten) weg, bei 1000 ms schaffe ich 100 %

Ich kenne mich leider (noch) zu wenig mit nodejs aus und auch mit dem ioBroker zugrunde liegenden Datenspeicher. Aber socketio ist schon mal ein guter Impuls, da werde ich mal schauen.

Mein nächster Versuch ist der Umzug von VMware auf Proxmox, dann habe ich damit schon mal eine ganz andere Virtualisierungsumgebung - sofern das was damit zu tun hat. Mal sehen...

UDP fände ich übel, schließlich haben wir ja keine Mediendaten oder so. Aber ich fände es toll wenn irgendwo ein Fehler geworfen würde, wenn Daten nicht korrekt geschrieben werden können. Irgendein Hinweis in irgendeinem Log. Wenn Daten stillschweigend verworfen werden und deswegen der Feuermelder, die Alarmanlage oder sonst was nicht auslöst, könnte das fatal sein...

[paul53]

@antimon sagte:

wenn Daten nicht korrekt geschrieben werden können.

Wie kommst Du darauf, dass sie nicht korrekt geschrieben werden ? Du prüfst nur zu früh (getState(id)) , ob sie geschrieben wurden.

[OliverIO]

@antimon ich glaube nicht das vmware daran schuld ist bzw. wenn wird es mit proxmox nicht besser sein.
vmware ist millionenfach auf der welt im profieinsatz in den Rechenzentren dieser welt.
Wenn dann liegt es an irgendeiner Konfiguration oder deinem Rechner (wobei xeon ist ja nicht der schlechteste prozessor).
aber da bin ich nicht so firm

alternativ kannst du docker probieren, wenn du nativ nicht installieren willst.
da ist zumindest die ganze hardware virtualisierung weg.

[antimon]

@paul53 said in Datenpunkte werden nicht immer gesetzt:

@antimon sagte:

wenn Daten nicht korrekt geschrieben werden können.

Wie kommst Du darauf, dass sie nicht korrekt geschrieben werden ? Du prüfst nur zu früh (getState(id)) , ob sie geschrieben wurden.

Also meine ursprüngliche Theorie kam dadurch zustande, dass Lichter sehr unzuverlässig geschalten wurden - mal gings, mal wieder nicht. Deswegen habe ich versucht, das Problem irgendwie einzugrenzen.
Werden die Daten denn mit setState() asynchron geschrieben? Wenn ja, was macht das für einen Sinn, wenn ich nicht sicher sein kann, ob und wann ein Datenpunkt korrekt geschrieben ist?
Und warum funktioniert meine Testroutine dann bei verschiedenen anderen Leuten zu 100% und bei mir nicht? Das müsste dann ja wirklich an der Performance liegen...

@OliverIO said in Datenpunkte werden nicht immer gesetzt:

@antimon ich glaube nicht das vmware daran schuld ist bzw. wenn wird es mit proxmox nicht besser sein.
vmware ist millionenfach auf der welt im profieinsatz in den Rechenzentren dieser welt.
Wenn dann liegt es an irgendeiner Konfiguration oder deinem Rechner (wobei xeon ist ja nicht der schlechteste prozessor).
aber da bin ich nicht so firm

alternativ kannst du docker probieren, wenn du nativ nicht installieren willst.
da ist zumindest die ganze hardware virtualisierung weg.

Also die Virtualisierung sollte nicht so das Problem sein, denke ich - ich stelle nur eh gerade von VMware auf Proxmox um, da bietet sich das als Test an. Die Virtualisierung nimmt zwar ein paar Prozente an Leistung weg, aber das ist normalerweise vernachlässigbar. Auf der Hardware laufen problemlos auch noch andere Maschinen, ohne dass da eine große I/O-Last wäre, aber ich möchte es trotzdem ausschließen.
Mit Docker bin ich ehrlich gesagt auf Kriegsfuß
Proxmox bietet auch LXC-Container an, aber ich denke, andere hier haben doch sicher auch ioBroker virtualisiert am laufen oder?

[paul53]

@antimon sagte:

Werden die Daten denn mit setState() asynchron geschrieben?

Ja.

[antimon]

Gut, das erklärt natürlich so einiges... wobei ich gerade noch nicht so den Sinn dahinter verstehe. Normalerweise müssten die States doch alle im Speicher gehalten werden, da sollte ein Schreibvorgang doch relativ schnell gehen, oder?

Gibt es denn so eine Art "pending operations" queue, in der alle ausstehenden Schreibvorgänge zu finden sind? Wenn es so etwas gäbe, müsste man die Länge davon überwachen können, um zu sehen, ob es Performanceprobleme gibt...
Bei mir scheint es ja irgendwo an der Performance zu liegen... zumindest macht es so den Eindruck.

Der Umzug auf Proxmox hat übrigens wie vermutet nichts gebracht - das Problem besteht genauso wie vorher.