Warnung : Reconnection to DB.
-
Hi klassisch!
Ich hab irgendwie nämlich das DSM-update in verdacht. weil in etwa seit dem update auf DSM 6.2 haben die Probleme angefangen.
root@orangepiplus2e:~# sudo blkid -o list -w /dev/null device fs_type label mount point UUID ------------------------------------------------------------------------------- /dev/mmcblk0p1 ext4 / a0d53bc8-e6d3-43f3-b24e-ef61ddd45725 /dev/mmcblk0 (in use) root@orangepiplus2e:~#Speicherbelegung:
root@orangepiplus2e:~# df -hT Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/mmcblk0p1 ext4 15G 3,5G 11G 26% / udev devtmpfs 10M 0 10M 0% /dev tmpfs tmpfs 403M 5,7M 398M 2% /run tmpfs tmpfs 1008M 0 1008M 0% /dev/shm tmpfs tmpfs 5,0M 4,0K 5,0M 1% /run/lock tmpfs tmpfs 1008M 0 1008M 0% /sys/fs/cgroup 192.168.178.100:/volume1/backup/ioBroker-REDIS-states nfs 2,7T 1,9T 803G 71% /mnt/Backup tmpfs tmpfs 1008M 0 1008M 0% /tmp tmpfs tmpfs 202M 0 202M 0% /run/user/0 192.168.178.100:/volume1/Kameraaufnahmen nfs 2,7T 1,9T 803G 71% /mnt/NASAuslastung:
root@orangepiplus2e:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 21:55:26: 1296MHz 0.52 20% 3% 11% 0% 3% 1% 39°C 0/8 21:55:31: 408MHz 0.48 10% 2% 6% 0% 0% 1% 34°C 0/8 21:55:36: 1008MHz 0.44 8% 3% 5% 0% 0% 0% 34°C 0/8 21:55:41: 408MHz 0.41 7% 2% 5% 0% 0% 0% 34°C 0/8 21:55:47: 408MHz 0.37 12% 3% 7% 0% 0% 0% 34°C 0/8 21:55:52: 408MHz 0.42 7% 2% 4% 0% 0% 0% 33°C 0/8 21:55:57: 408MHz 0.39 7% 2% 5% 0% 0% 0% 32°C 0/8 21:56:02: 408MHz 0.36 6% 2% 4% 0% 0% 0% 34°C 0/8^C root@orangepiplus2e:~#top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 827 root 20 0 207980 93616 3204 S 10,8 4,5 6:36.24 io.javascript.0 948 root 20 0 152144 37028 2416 S 8,5 1,8 0:31.44 io.opi.0 988 root 20 0 150568 35548 1904 S 6,9 1,7 3:34.85 io.sql.0 1094 root 20 0 181248 67872 3180 S 6,5 3,3 2:51.28 io.javascript.2 1110 root 20 0 178592 65860 2900 S 6,5 3,2 2:44.13 io.javascript.3 67 root rt 0 0 0 0 S 2,9 0,0 1:17.20 cfinteractive 661 root 20 0 209012 88836 2108 S 2,9 4,3 5:54.02 iobroker.js-con 762 root 20 0 164808 48060 1384 S 1,6 2,3 0:55.33 io.admin.0 801 root 20 0 126868 17720 1104 S 1,0 0,9 0:14.11 io.vis.0 4486 root 20 0 5028 1160 808 R 1,0 0,1 0:00.59 top 24 root 20 0 0 0 0 S 0,7 0,0 0:20.31 kworker/0:1 771 root 20 0 134580 21188 3140 S 0,7 1,0 0:48.94 io.web.0 821 root 20 0 116164 16192 2972 S 0,7 0,8 0:26.44 io.fritzbox.0 1067 root 20 0 145632 30292 3176 S 0,7 1,5 0:21.59 io.cloud.0 72 root 20 0 0 0 0 S 0,3 0,0 4:01.74 mmcqd/2 75 root 20 0 0 0 0 S 0,3 0,0 0:00.83 hdmi proc 79 root 20 0 0 0 0 S 0,3 0,0 0:03.01 kworker/3:2 650 root 20 0 0 0 0 S 0,3 0,0 0:02.58 kworker/2:2 777 root 20 0 122684 16584 1472 S 0,3 0,8 0:19.42 io.simple-api.0 815 root 20 0 116132 14184 680 S 0,3 0,7 0:14.24 io.nut.0 978 root 20 0 131320 16648 2216 S 0,3 0,8 0:13.70 io.hm-rpc.1 1057 root 20 0 123128 17508 1552 S 0,3 0,8 0:26.99 io.samsung.0 4498 root 20 0 1624 524 424 S 0,3 0,0 0:00.01 ping 1 root 20 0 4488 1376 320 S 0,0 0,1 0:06.77 systemd 2 root -2 0 0 0 0 S 0,0 0,0 0:00.03 kthreadd 3 root 20 0 0 0 0 S 0,0 0,0 0:12.67 ksoftirqd/0 5 root 20 0 0 0 0 S 0,0 0,0 0:00.26 kworker/u:0 6 root rt 0 0 0 0 S 0,0 0,0 0:00.04 migration/0 7 root rt 0 0 0 0 S 0,0 0,0 0:00.06 watchdog/0 8 root rt 0 0 0 0 S 0,0 0,0 0:00.04 migration/1Systemkonfig
root@orangepiplus2e:~# uname -rm 3.4.113-sun8i armv7l root@orangepiplus2e:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.11 (jessie) Release: 8.11 Codename: jessie root@orangepiplus2e:~# cat /proc/version Linux version 3.4.113-sun8i (root@xeon) (gcc version 5.5.0 (Linaro GCC 5.5-2017.10) ) #18 SMP PREEMPT Wed Jan 24 22:10:49 CET 2018 root@orangepiplus2e:~# npm -v 3.10.10 root@orangepiplus2e:~# node -v v6.14.3 -
Bin leider Laie, aber ich würde bei der Datenbank beginnen.
Kann man die zumindest temporär/versuchsweise auf den OPI legen?
Ich habe ja auch so eine DS215j und das ist eine lahme Ente. 512MB Speicher und Marvell Prozessorchen.
-
Ja, Dein OPI sieht in etwa aus wie meiner, ich würde sagen unauffällig.
Nehme an, die IP 100 ist die DS. Da gibts auch Verbindungen zu Kameraaufnahmen. Das könnte die DS auch belasten. Läuft da die Surveillance station durch? Wie sieht es aus, wenn man die anhält?
-
Vielleicht geht auch samba besser als nfs?
-
Wenn es nur die Datenbank wäre dann wäre auchnur der SQL-Adapter betroffen …
Interessant wäre es so einen Zeitpunkt wo da passiert "Beobachten" zu können. Mal collectd installieren und Daten sammeln lassen und dann schauen was zu sei einem Zeitpuntk auf dem Opi passiert?
-
Hab mal sql auf den opi gelegt und das selbe Problem.
Apollon wie verwende ich das collectd? Was muss ich da genau machen?
-
Hi,
Coolectd: Sorry, aber am besten befrag da mal Google. Du bräuchtest collectd auf dem Rechner und mus RRD Files schreiben mit den Daten und brauchst irgendwas zu visualisieren. Ist nur ne Idee … am Ende kommen wir hier nicht weiter es sei denn wir finden raus was hier zu den Zeitpunkten auf dem Rechner passiert.
Hast Du irgendwie ein Muster entdecken können wann es auftritt oder ist es komplett zufällig?
-
Ich hate auch diese Reconnection to DB Meldungen, Redis hat geholfen (Danke an Bluefox für den Tip).
-
Also nachdem ich komplett auf stable-Repo zurück bin läuft es auch wieder.
hmmm….ist jetzt bloß die Frage woran es lag.
-
Lässt sich jetzt eher schwierig sagen.
Kannst jetzt anfangen nacheinander die Adapter wieder auf latest zu ziehen und schauen wann es startet
-
So werd ich es auch machen. Muss bloß noch auf meinen NUC warten. Dann ziehe ich erstmal mein Produktivsystem auf den NUC und mache mit dem OPi den test.
-
Freut mich, daß es jetzt wieder läuft! Bei mir war das anders, downgraden brachte zwar etwas Linderung, aber keine Heilung.
-
Ich habe auch node komplett deinstalliert und neu installiert.
Node 6.14.3
Npm 3.10.10
Und ein reinstall.sh laufen lassen.
-
Nachdem ich
js-controller -> 1.4.2
admin -> 3.4.7
web -> 2.4.6
upgedatet habe, bekomme ich die "reconnection to db" auch beim Lesen.
Wenn ich Firefox mit 36 Flot-Charts und 2 einfachen vis öffne, kommt diese Meldung.
Ursprünglich gefolgt von einem lästigen Neustart des history Adapters.
Nach einem Neustart des hosts bleibt der Neustart (noch) aus.
Derzeit habe ich eine 32GB SSD über USB am OPi für History. Habe hier noch eine 60GB liegen, die etwas schneller schreibt und liest. Mal am WE versuchen, ob ein Wechsel auf die schnellere 60GB SSD hilft.
-
Hey,
Also 36 Flot Graphen bedeutet das parallel 36 Prozesse losgetreten werden die Daten lesen wollen.
Im neuen js-Controller 1.5.0 der seit gestern im latest ist ist mal mindestens der lästige Neustart von History nicht mehr da. Könntest du mal versuchen. Siehe Tester Thread gibt es aber scheinbar damit gerade noch ein ssl Thema …
Gesendet vom Handy ...
-
Also 36 Flot Graphen bedeutet das parallel 36 Prozesse losgetreten werden die Daten lesen wollen. ` ja , das mache ich schon geraume Zeit so. ich will das System ja nicht nur haben, sondern auch nutzen
um weitere Investitionen oder Umbauten zu vermeiden, könnte ich das jetzt in zwei 18er Gruppen aufteilen und nacheinander abrufen. ich werde das mal testen.
Im neuen js-Controller 1.5.0 der seit gestern im latest ist ist mal mindestens der lästige Neustart von History nicht mehr da. Könntest du mal versuchen. Siehe Tester Thread gibt es aber scheinbar damit gerade noch ein ssl Thema … ` vielen Dank, das klingt doch schon mal sehr gut. Der Log Eintrag stört mich weniger . Lästig sind die Neustarts von History. Zumal die bei mir von Neustart zu Neustart träger werden.
Ssl nutze ich innerhalb von ioBroker (noch) nicht. Und ich denke der Putty Zugang geht dir einen anderen Weg.
Gesendet von meinem ZTE A2016 mit Tapatalk
-
Ja die Neustarts sind blöd und damit rechnet der Adapter nicht und dann pasieren ggf komische Dinge … Versuch mal die 1.5.0. Schu aber im testing Thread!
-
Ja, sieht bisher sehr gut aus!
Habe jetzt einige solcher "Stresstests" durchgeführt. Man sieht im armbianmonitor, daß der Opi ackern muß.
Aber kein Problem im Log, nichtmal eine Reconnection to DB Meldung.
Vielen Dank!
-
Cool super
Gesendet vom Handy …
-
ich kram mal den Thread raus..
bekomme die Meldung seit paar Tage nauch zu sehen… warum auch immer..
Master Docker auf Synology 10Gb RAM -> Redis -> MYSQL für History
Multihost Pi1 (slave Pi mit HDD)
Multihost Pi2 (SD)
den Reconnect bekomme ich auf javascript das auf dem Slave Pi1 läuft..kommt aber auch nur sporadisch vor ..
