Bewährte Histogrammfunktion?

[klassisch]

@homoran Naja, in den Adaptereinstellungen habe ich schon mal Kontakt zur Datenbank. Aber die Adaptereinstellungen lassen sich nicht speichern. Das hatte ich auch noch nie. Da sind rote Rahmen um die Buttons

Wieder eine neue Schikane des neuen Admins?

[Homoran]

@klassisch sorry, ist jetzt 6 Jahre her, wenn ich dem verlinkten Thread glauben darf.

ich hab da ewig nichts mehr gemacht.

[klassisch]

@homoran War wahrscheinlich Schikan/Bug im neuen Admin oder dem SQL Adapter.
Habe MS_SQL ausgewählt. Die hat nicht connected. Wieder zurück auf MySQL und dann konnte ich abspeichern

[klassisch]

Habe mal 3 Datenpunkte auf loggen gestellt.
Fehlermeldungen, access denied

Man muß bei Heidi globale Rechte anhaken

Jetzt hat er das logging bestätigt und auf der Zielplatte tut sich was.

Mal abwarten wie es morgen früh dort aussieht.

[klassisch]

Das Logging hat funktioniert. Mit Flot kann ich die Datenpunkte sehen.
Der ioBroker Rechner war heute morgen mit dem ioBroker Prozess bei etwa der zehnfachen Prozessorlast. Nach Restart von ioBroker war das iO. Keine Ahnung woher das kommt. Hatte ich so gefühlt noch nie, muß ich beobachten.

Grafan ist auf meinem Arbeitsrechner installiert wird aber vom Server abgelehnt. Da scheint es noch Rechteproblem zu geben.

@BananaJoe Wo läuft Dein Grafana? Auf Deinem Arbeitsrechner (Client) oder auf Deinem ioBroker Server?

[BananaJoe]

@klassisch kein Grafana, SQL-Adapter und eCharts reichen mir.

Im MySQL gibt es ein Binding:

bind-address            = 0.0.0.0

Dann ist der Zugriff von außen erlaubt, steht da 127.0.0.1 ist nur lokaler Zugriff erlaubt.
Für jeden Zugriff muss ein Benutzer eingerichtet werden, also auch für jeden entfernten Netzwerkzugriff:

benutzer@127.0.0.1
benutzer@192.168.0.126

kann sein das auch benutzer@* möglich wäre.
Im Screenshot von HeidiSQL sieht man das bei "Kommt von Host"

[BananaJoe]

@klassisch naja, jetzt darf er alle Datenbanken, iobroker müsste auf der Datenbank berechtigt werden mit vollzugriff.
Aber so geht es auch, ist aber nicht so gewollt

[klassisch]

@bananajoe Sorry, das habe ich nicht verstanden.
Ist der "global" Haken bei Heidi nicht in Ordnung?

Durch einen neuen user kommt Grafana einen Schritt weiter und testet irgendwas. Darf dann aber doch irgendwie nicht.

Zu viele Benutzer, zu viele Rechte, Fehlermeldung zu unspezifisch.

lEin Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat."
logger=context t=2022-03-25T10:55:26.63+0100 lvl=info msg="Request Completed" method=POST path=/api/ds/query status=400 remote_addr=127.0.0.1 time_ms=21045 size=233 referer=http://localhost:3000/datasources/edit/-JNX6my7z

In den 70ern und 80ern hat unsere Univac auch immer gesagt "USR did ERR". War etwa genauso aufschlußreich....

[BananaJoe]

@klassisch pff da bin ich der falsche. Ich mache das inzwischen seit über 20 Jahren und lege meine Datenbanken z.B. per

reate database iobroker character set utf8 collate utf8_bin;
create user 'iobroker'@'localhost' identified by 'test1234'
grant all privileges on iobroker.* to 'iobroker'@'localhost'

legte eine Datenbank iobroker an auf die ein lokaler Benutzer / ein Benutzer ausschließlich lokal zugreifen kann der iobroker heißt und das Passwort test1234 hat.

Ich kenne HeidiSQL zwar, nutze das aber nur sehr selten.

Ich bin so alt, meine Musik und Bilder sind noch Ordner sortiert, nicht nach Tags oder Metadaten.

[klassisch]

Noch ne Frage.MariaDB läuft bei mir derzeit im Probebetrieb. Aber alle paar Tage bekomme ich logeinträge mit Fehlermeldungen.
Der Dienst MariaDB läuft dann nicht mehr und muß neu gestartet werden.
Habe ich da irgendeine Option vergessen, daß das Ding durchläuft? Gibt es da ein timeout?

[BananaJoe]

@klassisch wie wäre der Inhalt des Logs denn? Es gibt bei normalen Installationen unter var/log/mysql/error.log ein Log im welchen der Grund stehen sollte. (Ja, Ordner mysql auch bei mariadb, zumindest unter Ubuntu, Ordner mariadb aber auch möglich)

Vermutlich so etwas wie out of Memory (rate ich jetzt einfach mal) was auch davon abhängt wie der Server Konfiguriert ist. Ist jedenfalls der häufigste Grund warum der nach ein paar Tagen aufgeben sollte. Insbesondere wenn mehr Cache konfiguriert ist RAM vorhanden ist.

[klassisch]

@bananajoe Vielen Dank,
Unter Win sind die Namen anscheinend anders.
Da gibt es auf der Datenplatte unter

Rechnername.err

ein Logfile

Ich zitiere mal, was ich kurz vor bzw. dem letzten Absturz halte

2022-03-25 17:42:48 59 [Warning] Aborted connection 59 to db: 'unconnected' user: 'unauthenticated' host: 'DESKTOP-NAME.fritz.box' (This connection closed normally without authentication)
2022-03-25 17:44:57 134 [Warning] Access denied for user 'pcuser'@'DESKTOP-NAME.fritz.box' (using password: YES)
2022-03-25 17:45:58 169 [Warning] Access denied for user 'pcuser'@'DESKTOP-NAME.fritz.box' (using password: YES)

Also es scheint irgendein Rechteproblem zu sein.
Ich wart mal den nächsten Crash ab und schaue dann im log nach BEVOR ich neu starte. Dann erwische ich zumindest hoffentlich die richtige Stelle.

Speicher habe ich 8GB auf meinem i5. Und der Task Manager zeigt jetzt keine auffällige Speicherbelegung durch MariaDB

[BananaJoe]

@klassisch wenn die Datenbank steht, die letzten 10 Zeilen wären interessant (ggf. mehr, alles was du in den letzten Sekunden kommt). Bevor du die wieder startest.

Ich bin sicher die stürzt nicht ab sondern beendet sich wegen eines Grundes selbst.

[klassisch]

@bananajoe Danke, momentan läuft sie gerade (noch). Beim nächsten ungewollten Beenden schaue ich im log nach.
Kann man da ein loglevel einstellen? Soll ich da etwas höher stellen?

[BananaJoe]

@klassisch könnte man wohl aber bisher hatte bei solchen Fehlern der Standard gereicht.

[klassisch]

@bananajoe gestern Abend hat MariaDB wieder gestreikt

Im ioBroker sieht das log so aus:

2022-03-30 17:34:50.601  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654479478, 997, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.618  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654486481, 3000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.620  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654465480, 998, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.622  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(1, 1648654485012, 615.7, 1, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartmeterReading)
2022-03-30 17:34:50.625  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654488487, 996, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.628  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654483480, 1000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.637  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654482480, 1000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.640  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654469479, 999, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.643  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654474480, 994, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.649  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654467480, 995, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.650  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654472479, 1000, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.653  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(1, 1648654470014, 610.5, 1, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartmeterReading)
2022-03-30 17:34:50.655  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654480480, 1002, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:50.658  - error: sql.0 (13376) Cannot insert INSERT INTO `iobroker`.ts_number (id, ts, val, ack, _from, q) VALUES(3, 1648654475488, 1007, 0, 2, 0);: Error: read ECONNRESET (id: 0_userdata.0.power.smartMeterSampleTime)
2022-03-30 17:34:51.487  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:52.486  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:54.485  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:56.482  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:57.485  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306
2022-03-30 17:34:58.488  - error: sql.0 (13376) Error: connect ECONNREFUSED 127.0.0.1:3306

Es scheint also Probleme mit dem Datenpunkt "smartMeterSampleTime" zu geben. Der wird von einem Script etwa sekündlich erzeugt und läuft stabil durch. Also auch jetzt noch.

Im Errorlog von MariaDB selbst war da gar nichts zu sehen. Da sieht man nur den letzten Start

2022-03-28  8:05:24 0 [Note] InnoDB: Starting final batch to recover  540 pages from redo log.
2022-03-28  8:05:24 0 [Note] InnoDB: 128 rollback segments are active.
2022-03-28  8:05:24 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2022-03-28  8:05:24 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-03-28  8:05:24 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-03-28  8:05:24 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-03-28  8:05:24 0 [Note] InnoDB: 10.7.3 started; log sequence number 32056487; transaction id 313154
2022-03-28  8:05:24 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-03-28  8:05:24 0 [Note] InnoDB: Loading buffer pool(s) from F:\mariadb\data\ib_buffer_pool
2022-03-28  8:05:24 0 [Note] InnoDB: Buffer pool(s) load completed at 220328  8:05:24
2022-03-28  8:05:24 0 [Note] Server socket created on IP: '::'.
2022-03-28  8:05:24 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-03-28  8:05:26 0 [Note] C:\Program Files\MariaDB 10.7\bin\mysqld.exe: ready for connections.
Version: '10.7.3-MariaDB'  socket: ''  port: 3306  mariadb.org binary distribution

[BananaJoe]

@klassisch wenn es das error.log ist dann läuft aus dessen Sicht der dienst noch.

ok Windows - Was sagt denn das Ereignisprotokoll? Auch Eventlog genannt, das von Windows selbst.
Es gibt einen Dienst für MariaDB, richtig? Der auf Automatisch steht. In den Erweiterten Einstellungen kann man dort setzen das er den Dienst bei einem Fehler wieder neu startet (was zwar die Symptome lindert habe den Grund nicht erklärt)

[klassisch]

@bananajoe Ja, vielen Dank, di Ereignisanzeige sagt was:

• Fehler 17:34, MariaDB: InnoDB: Operating system error number 55 in a file operation.

• Info 17:34 MariaDB: InnoDB: Some operating system error numbers are described at https://mariadb.com/kb/en/library/operating-system-error-codes/ . Der Link führt zu einer Website und dort steht unter 55:
  "55 ENOANO No anode" .

• Fehler 17:34 MariaDB: InnoDB: File (unknown): 'flush' returned OS error 255. Cannot continue operation

• Fehler 17:34 Application Error: Name der fehlerhaften Anwendung: mysqld.exe, Version: 10.7.3.0, Zeitstempel: 0x6205972c

  • Name des fehlerhaften Moduls: server.dll, Version: 10.7.3.0, Zeitstempel: 0x62059706
  • Ausnahmecode: 0x80000003
  • Fehleroffset: 0x00000000003e8582
  • ID des fehlerhaften Prozesses: 0x333c
  • Startzeit der fehlerhaften Anwendung: 0x01d84269cde184f4
  • Pfad der fehlerhaften Anwendung: C:\Program Files\MariaDB 10.7\bin\mysqld.exe
  • Pfad des fehlerhaften Moduls: C:\Program Files\MariaDB 10.7\bin\server.dll
  • Berichtskennung: fd3a5e4e-dbdb-4b02-ad2b-e68ce2eef71f
  • Vollständiger Name des fehlerhaften Pakets:
  • Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

• 17:34 Win Error Reporting

  • Fehlerbucket 1742235423834438271, Typ 4

  • Ereignisname: APPCRASH

  • Antwort: Nicht verfügbar

  • CAB-Datei-ID: 0

  • Problemsignatur:

  • P1: mysqld.exe

  • P2: 10.7.3.0

  • P3: 6205972c

  • P4: server.dll

  • P5: 10.7.3.0

  • P6: 62059706

  • P7: 80000003

  • P8: 00000000003e8582

  • P9:

  • P10:

  • Angefügte Dateien:

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2CE7.tmp.dmp

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp

  • \WER2D94.tmp.WERInternalMetadata.xml

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2DC4.tmp.xml

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2DC2.tmp.csv

  • \?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER2E01.tmp.txt

  • Diese Dateien befinden sich möglicherweise hier:

  • \?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive

  • \AppCrash_mysqld.exe_8bb04fadc453dbcb7177ab22926491040a8e4dc_48e38982_45e41aa6-c491-4535-8a75-0ed9d29c1cbe

  • Analysesymbol:

  • Es wird erneut nach einer Lösung gesucht: 0

  • Berichts-ID: fd3a5e4e-dbdb-4b02-ad2b-e68ce2eef71f

  • Berichtstatus: 268435456

  • Bucket mit Hash: 99f2dff1847fb019d82da9e320c0fa7f

  • CAB-Datei-Guid: 0

Die verlinkten Dateien sind entweder nicht (mehr) vorhanden oder access denied.

MariaDB scheint also Probleme mit dem Filesystem oder einem "Flush" zu haben.

Ich lege die Daten auf einer externen Platte ab, auf der ich auch die history Daten und andere Daten eines anderen Vielschreiber-Programms ablege.

Beim nächsten "Husten" versuche ich mal die Daten auf die Syste-SSD zu schreiben - was ich eigentlich vermeiden wollte.

Ich vermute mal - ohne eine wirkliche Ahnung zu haben - daß die Implementierung unter Windows nicht ganz so robust zu sein scheint. Wäre schade.

Edit: zu ENOANO findet man bei https://unix.stackexchange.com/questions/167368/what-is-enoano-no-anode-intended-to-be-used-for eine Antwort, bei der jemand richtig tief recherchiert hat.

Das scheint uralt zu sein, noch von Convergent/Burroughs Unix (CENTIX) stammend. Hat sich irgendwie durchgeschleppt, geriet aber in Vergessenheit

"So ENOANO probably indicated that either the kernel had run out of memory for inodes, or that the filesystem's inode table was full, in some commercial Unix in the 1980s. That Unix is now forgotten, its terminology is now forgotten, and due to some quirk the error code has stayed around."

[BananaJoe]

@klassisch der Dienst läuft unter welchen Benutzer?
Und die Datenbank auf einer USB-Festplatte abzulegen ist denkbar doof (wenn ich das richtig verstanden habe)

kein Zugriff ... es ist wichtig das der Benutzer unter dem MariaDB läuft zugriff hat. Wenn das SYSTEM ist sollte alles ok sein.

[klassisch]

@bananajoe Vielen Dank!
Das sieht interessant aus:

Keine Ahnung wie das zustande kommt und ob/wie ich das ändern könnte.

Ja, SSD wäre blöd, deshalb ist das derzeit eine WD purple, die ohnehin 24/7 läuft, wofür sie auch ausgelegt ist.

Aber wegen der "Flush" Thematik hätte ich das halt probeweise auf die SSD gelegt bis das Problem behoben ist.