[Gelöst]no connection to database
-
Dort taucht bei mir in beiden Fällen gar nichts auf, weder bei dmesg -wT noch bei iobroker logs --watch.
Allerdings melden mehrere Adapter während der ioBroker aktiv ist
2021-08-26 20:01:36.686 - warn: info.0 (3195) slow connection to states DB. Still waiting ...Zudem ist mir aufgefallen dass meine Influx DB für Grafana auch nicht mehr erreichbar ist.
-
Keine Ahnung warum da die I/O-Last offenbar so hoch ist.
Unnötiger Krempel am Start? Desktop-Umgebung? Remote-Desktop gar? -
Problem mit no conection to database hatte ich auch mal.....
Abhilfe schaffte folgender Vorschlag von apollon77
apollon77
- Mai 2021, 23:38
@lausid Also das passiert an sich nur wenn die SD oder platte eccht beschäftigt ist oder die Kiste und die DB Verbindung zu lange dauert (2s sind eingestellt).
Dann auf die Harte tour:
Editiere /opt/iobroker/iobroker-data/iobroker.jsonund unter objects und states bigs ein
"connectTimeout": 2000,
mach mal 5000 draus.
Gruß LausiD
-
@lausid Wobei man mal schauen sollte, was da für soviel Verkehr auf dem Bus sorgt das es sich da staut.
-
@thomas-braun
Ist nen Pi4 mit 4GB Ram und Raspbian Buster ohne Desktop. Außer ioBroker, Grafana und InfluxDB läuft nichts drauf.
Könnte mir höchstens vorstellen dass die SD Karte schlapp macht, ist nur komisch dass es nun direkt nach den Updates auftaucht und Nutzer wie Chaos offenbar das gleiche Problem haben. -
-
@lausid
Danke, nun tut sich was.
@Thomas-Braun liefere ich gleich nach sobald ich durch bin.
edit: zu früh gefreut. Nachdem nun iobroker upgrade & iobroker upgrade self ohne db fehler anlief kommt nun im Verlauf des versuchten JS Controller upgrades
pi@raspi4:~ $ iobroker upgrade self Update js-controller from @3.2.16 to @3.3.15 NPM version: 6.14.14 npm install iobroker.js-controller@3.3.15 --loglevel error --unsafe-perm --prefi x "/opt/iobroker" (System call) Objects database error: connect ECONNREFUSED 127.0.0.1:9001 States database error: connect ECONNREFUSED 127.0.0.1:9000 -
mein "top"
top - 21:29:08 up 1:33, 3 users, load average: 2,27, 2,70, 3,25 Tasks: 134 total, 1 running, 133 sleeping, 0 stopped, 0 zombie %Cpu(s): 32,5 us, 2,1 sy, 0,0 ni, 65,4 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st MiB Mem : 3838,7 total, 2883,8 free, 187,7 used, 767,2 buff/cache MiB Swap: 100,0 total, 100,0 free, 0,0 used. 3465,4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27611 influxdb 20 0 944900 78732 41216 S 128,1 2,0 0:09.25 influxd 27522 pi 20 0 10332 2980 2436 R 1,0 0,1 0:00.25 top 12 root 20 0 0 0 0 I 0,3 0,0 0:12.89 rcu_sched 594 mysql 20 0 723752 66628 15324 S 0,3 1,7 0:13.93 mysqld 27610 influxdb 20 0 7808 2664 2488 S 0,3 0,1 0:00.04 influxd-systemd 1 root 20 0 32712 8084 6468 S 0,0 0,2 0:17.56 systemd 2 root 20 0 0 0 0 S 0,0 0,0 0:00.03 kthreadd 3 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_par_gp 8 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 mm_percpu_wq 9 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_tasks_rude_ 10 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_tasks_trace 11 root 20 0 0 0 0 S 0,0 0,0 0:07.88 ksoftirqd/0 13 root rt 0 0 0 0 S 0,0 0,0 0:00.74 migration/0 14 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/0 15 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/1 16 root rt 0 0 0 0 S 0,0 0,0 0:00.72 migration/1 17 root 20 0 0 0 0 S 0,0 0,0 0:02.24 ksoftirqd/1 20 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/2 21 root rt 0 0 0 0 S 0,0 0,0 0:00.64 migration/2 22 root 20 0 0 0 0 S 0,0 0,0 0:02.44 ksoftirqd/2 25 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/3 26 root rt 0 0 0 0 S 0,0 0,0 0:00.58 migration/3 27 root 20 0 0 0 0 S 0,0 0,0 0:02.44 ksoftirqd/3 29 root 0 -20 0 0 0 I 0,0 0,0 0:08.48 kworker/3:0H-kblockd 30 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs 31 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 netns 34 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kauditd 36 root 20 0 0 0 0 S 0,0 0,0 0:00.00 khungtaskd 37 root 20 0 0 0 0 S 0,0 0,0 0:00.00 oom_reaper 38 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 writeback 39 root 20 0 0 0 0 S 0,0 0,0 0:00.58 kcompactd0 57 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kblockd 58 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 blkcg_punt_bio 59 root -51 0 0 0 0 S 0,0 0,0 0:00.00 watchdogd 62 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rpciod 63 root 0 -20 0 0 0 I 0,0 0,0 0:00.05 kworker/u9:0-hci0 64 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 xprtiod 65 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kswapd0 66 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 nfsiod 67 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kthrotld 68 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 iscsi_eh 69 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 iscsi_destroy 70 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 nvme-wq 71 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 nvme-reset-wq 72 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 nvme-delete-wq 76 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 DWC Notificatio 77 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 uasDie CPU Usage der InfluxDB ist nicht normal oder? Wobei er extrem zwischen 10 und 120% schwankt
Werde es mal stoppen und nochmals versuchen.
-
@leif1 Nee...
Leg die mal auf Eis. Mindestens während des upgrades. -
Nochmals vielen Dank für die Hilfe - nun läuft wieder alles.
Ein kleiner Nachtrag in der Hoffnung dass er vielleicht auch @chaos99 helfen könnte:
In meinem Fall war die Hauptursache wohl wirklich InfluxDB. Zunächst bekam ich dies auch nicht mehr ans laufen, bis ich folgenden Beitrag mit Problemen zu relativ frischen InfluxDB Versionen fand
link textEin erhöhen des Sleep von 1 auf 10 im InfluxDB Startscript löste dann auch das Problem, auch wenn das sicherlich keine ideale Lösung sein mag und der Fehler wohl irgendwo in den jüngsten InfluxDB Versionen liegt.
