NEWS
Orange Pi Plus 2e
-
mit dem oPI +2e hatte ich , beginnend vor so 6 wochen etwa auch probleme.
sporadische Neustarts, im Abstand von 2-7 Tage, kam aber nach neustart nicht wieder richtig hoch. Das gleiche, was hier auch aufgrtreten ist,
zuerst hatte ich den oPi im verdacht, also den 2. oPI startklar gemacht. restore eingespielt. Nach ein paar Tagen das gleiche Spiel. Also das Netzteil im Verdacht gehabt. Also lief dann der oPI, mit zig Kühlkörpern auf den chips, direk angelötet an einem Labornetzteil mit 5A.Auch hier 2 unkontrolierte Neustarts. Damit schliesse ich Spannungsversorgung nun aus,
Das Tinkerboard startklar mit einem raspberry 5.1V 2.5A Netzteil gemacht, backup eingespielt. seitem rennt das maschinchen durch.
Ich habe da den Opi unter verdacht. Entweder ein HW Komponente oder aber irgendwas mit einem der leztten Softwareupdates..
Seit ca 3 Wochen läuft IObroker bei mir nun auf einem Tinkerboard, mittlerweile samt SUSV.
Gruss, Black
-
Du kannst den backitup-Adapter so wie alle anderen Adapter mit den Systemstates des jeweiligen Adapters monitoren.
Dazu den Wert memRss über den History-Adapter wegschreiben und über die Zeit auswerten. memRss ist der komplette Speicher eines Prozesses im RAM mit Code, Stack und Heap.
-
@stabilostick : Vielen Dank für den Hinweis! Bei mir haben einige Adapter einen Wert namens "output count", der bei allen auf "8 events / 15 seconds" zu stehen scheint. Was hat es damit auf sich?
@blackmike : Interessant! Hatte anfangs des Jahres nach einem armbian Kernel Update Probleme mit history und DB reconnects bis hin zu Neustarts. An Ende lag es daran, daß ich die history Daten auf eine FAT32 formatierte SSD schrieb. Nach Umstellung auf ext4 SSD war das Problem weg; seither schnurrt der OPI wieder wie zuvor. armbian hatte also nach dem Kernel-Update die Fähigkeit verloren mit FAT32 so umzugehen wie in der Zeit zuvor.
Habe mir damals vorgenommen, bei der nächsten größeren Problemwelle auf einen alten Laptop unter Windows zu gehen. Da hätte ich allerdings keine Lösung für den Umgang mit den seit Win 10 nicht mehr steuerbaren Updates.
Habe jetzt seit wenigen Wochen auf einem anderen OPI piVCCU. Das läuft bisher auch stabil, wobei das auch kaum Last generiert.
-
Das mit den 8 Events beim outputCount ist ok. Sie entstehen u.a. durch die zyklischen Abfragen durch den js-Controller um den Status der Adapter auszulesen.
-
Ich kämpfe immer noch mit dem Memeory Verbrauch. Irgendwie scheint der nicht mehr freigegeben zu werden.
Hier eine "top" Anzeige:
top - 10:15:42 up 1 day, 1:37, 1 user, load average: 0.73, 0.48, 0.32 Tasks: 130 total, 1 running, 82 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.1 us, 0.8 sy, 0.0 ni, 97.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 2062388 total, 441772 free, 703456 used, 917160 buff/cache KiB Swap: 131068 total, 131068 free, 0 used. 1288416 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1077 root 20 0 203308 100752 17336 S 4.3 4.9 140:28.20 iobroker.js-con 883 mysql 20 0 635896 79548 12084 S 0.3 3.9 12:41.71 mysqld 1676 root 20 0 169228 70908 17028 S 1.6 3.4 36:55.28 io.javascript.0 1668 root 20 0 158620 59456 17900 S 1.3 2.9 58:40.35 io.sql.0 13767 root 20 0 158320 57260 17092 S 0.0 2.8 3:38.90 io.admin.0 1738 root 20 0 149744 48028 17128 S 0.3 2.3 16:08.35 io.web.0 1557 root 20 0 138652 47320 16924 S 0.0 2.3 5:08.57 io.opi.0 623 root 20 0 362680 44612 9560 S 0.0 2.2 4:08.81 java 1545 root 20 0 140492 43080 19700 S 0.0 2.1 1:32.66 io.ham.0 1371 root 20 0 141900 42416 17524 S 0.3 2.1 3:57.63 io.telegram.0 1551 root 20 0 142824 41496 28228 S 0.0 2.0 1:52.60 io.amazon-dash. 1662 root 20 0 137004 39092 17160 S 0.0 1.9 4:13.78 io.hm-rega.0 10494 root 20 0 128464 38504 17136 S 0.0 1.9 3:23.15 io.hm-rpc.2 1656 root 20 0 128492 38176 17168 S 0.0 1.9 7:21.93 io.hm-rpc.0 1395 root 20 0 124016 33272 17076 S 0.3 1.6 1:15.48 io.socketio.0 1497 root 20 0 122484 32308 17112 S 0.3 1.6 5:02.23 io.hm-rpc.1 1569 root 20 0 126172 32224 17644 S 0.0 1.6 1:16.53 io.alexa.0
Hier sieht man schön, dass der Memeory immer schön abnimmt. Der Knick gegen 9:10 ist ein Backup (backup Adapter). Bald knallt es dann wieder.
Gruß
Holger
-
Sorry, hatte eine recht volle Woche und Abends leider kaum Zeit. Habe am 19.7. mal meinen OPi Adapter aktiviert.
So sieht es bei mir aus. Keine so großen bleibenden Sprünge, dafür recht lebhaft. Zeitskala deckt aber einige Tage ab. Man koennte eine Tendenz hineininterpretieren. Würde ich aber noch nicht tun. Ich lassen den Monitor noch etwas laufen.Den Backitup Adapter habe ich nicht. Habe das alles "zu Fuß" über shell, rsync etc eingerichtet. Sicher alles suboptimal, da ich kein Linux-Spezi bin, aber es scheint hinreichend zu laufen.
-
Kann es sein, dass Du Dir den Free-Speicher anzeigen lässt?
KiB Mem : 2062388 total, 441772 free, 703456 used, 917160 buff/cacheBetrachte mal lieber die Kombo aus Free und Buffer. Wenn beides zusammengezählt knapp 0 ergibt, DANN hast Du ein Problem.
Ganz frei nach https://www.linuxatemyram.com/
-
Tut er!
Dabei hat er noch fast 1GB Cache
Gruß Rainer
-
Fast mehr als mein RPI überhaupt eingebaut hat. Kann ich tauschen? :)
-
Die Varianz (Sprünge) ist auch ein interessantes Maß, nicht nur der absolute Wert und die Tendenz. Habe gehört, dass in Node 8.6? da ein Thema mit der Garbage Collection war, mit Node 8.9 gefixed. Danke für den Hinweis, behalte ich im Hinterkopf.
-
Bei mir arbeiten gerade diese Versionen:
root@opi2e_ioBroker:~# npm -v 3.10.10 root@opi2e_ioBroker:~# node -v v6.14.3 root@opi2e_ioBroker:~# -
Kann es sein, dass Du Dir den Free-Speicher anzeigen lässt?
KiB Mem : 2062388 total, 441772 free, 703456 used, 917160 buff/cacheBetrachte mal lieber die Kombo aus Free und Buffer. Wenn beides zusammengezählt knapp 0 ergibt, DANN hast Du ein Problem.
Ganz frei nach https://www.linuxatemyram.com/ `
Danke für den Link. Sieht also erstmal garnicht so schlecht aus:
total used free shared buff/cache available
Mem: 2014 668 464 9 881 1277
Swap: 127 0 127
Leider gibt der OPI Adapter den "Available" nicht als Datenpunkt raus.
Und leider habe ich jetzt immer noch keinen Anhaltspunkt warum die Kiste hängenbleibt (Wobei habe gerade ne Up Time > 2 Tage ;-)
Gruß
Holger
-
Die neuen Kühlkörper 35mm x 35mm x 16mm passen genau:
Und sie wirken auch12:04:11: 1296MHz 0.00 0% 0% 0% 0% 0% 0% 32.4°C 0/9^X 12:04:16: 1296MHz 0.00 0% 0% 0% 0% 0% 0% 32.8°C 0/9^C root@opi2e_reserve:~# sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) && armbianmonitor -m sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 105.0442s total number of events: 10000 total time taken by event execution: 420.0851 per-request statistics: min: 41.97ms avg: 42.01ms max: 68.50ms approx. 95 percentile: 42.02ms Threads fairness: events (avg/stddev): 2500.0000/1.22 execution time (avg/stddev): 105.0213/0.02 Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 12:06:22: 1296MHz 3.31 3% 0% 3% 0% 0% 0% 48.4°C 0/9 12:06:27: 480MHz 3.04 0% 0% 0% 0% 0% 0% 37.4°C 0/9 12:06:32: 1296MHz 2.80 0% 0% 0% 0% 0% 0% 37.0°C 0/9 12:06:37: 1296MHz 2.58 0% 0% 0% 0% 0% 0% 36.8°C 0/9 -
Super!
dafür passt das neue Funkmodul nicht :(
ich dachte, da es ein gespiegelte GPIO-Leiste hat passt das Modul jetzt über Kopf überdie Platine (damit wird die Idee natürlich ad absurdum geführt) aber passt schon wegen der NIC Buchse nicht
Gruß
Rainer
-
Auf dieses Problem bin ich ja gar nicht erst aufgelaufen, weil ich das billigere alte in einem abgesetzten Gehäuse und mit einem zusätzlichen 3,3 V Linearregler verwende. und diese Kombination kann ich nur wärmstens empfehlen.
Gesendet von meinem ZTE A2017G mit Tapatalk
-
Leider gibt der OPI Adapter den "Available" nicht als Datenpunkt raus.
Und leider habe ich jetzt immer noch keinen Anhaltspunkt warum die Kiste hängenbleibt (Wobei habe gerade ne Up Time > 2 Tage `
Schau dir mal den Beitrag viewtopic.php?f=8&t=15457&hilit=Available+ram an und dort ganz unten memAvailable.
-
Hier eine kurze Info zum Thema Backup des EMMC auf SD Karte:
ich habe mir heute das Script nand-sata-install etwas genauer angeschaut.
Beim OPi wird die SD-Karte über /dev/mmcblk0 und das EMMC über /dev/mmcblk1 angesprochen.
Das Script nand-sata-install prüft, ob die aktuelle Root-Partition auf mmcblk0 oder mmcblk1 liegt und wählt dann die als Destination das jeweils andere Device als Installationsziel aus. Wurde das System von der SD-Karte gebootet, ist das Installationsziel somit der EMMC Speicher. Wurde das System vom EMMC gebootet, ist das Installationsziel die SD Karte.
Ein vollständige und bootfähige Kopie des EMMC auf SD-Karte lässt sich daher recht einfach erstellen:
Formatierte SD-Karte ohne System einlegen, von EMMC booten, nand-sata-install ausführen, EMMC als Ziel auswählen.
Danach 35 Minuten Gedult und fertig.
Viele Grüße
Stefan
-
Vielen Dank für die Info!
Bootet der OPi wenn eine SD-Karte drin steckt? Dachte da gibt es einen Kontakt, der das detektiert?
Oder muß man die SD nach dem booten einstecken?
Und eMMC als Ziel wählen oder SD?
-
Ich habe die SD-Karte zunächst am PC formatiert mit FAT32, sonst nichts.
Dann in OPi reingesteckt und den OPi eingeschaltet => OPi muss von EMMC booten, da auf der SD Karte nichts darauf ist.
Nachdem der OPi hochgefahren ist, habe ich das script nand-sata-install unter root gestartet und dort die Option EMMC als Ziel ausgewählt.
(Es gibt eine Option SD-Karte zusammen mit USB-Stick/sata-Platte, diese ist aber nicht richtig, da wird nur die Boot-Partition auf der SD-Karte erzeugt das Root-Verzeichnis landet bei dieser Option auf dem USB-Stick/sata-Platte)
Wenn das Script durchgelaufen ist, erscheint die Poweroff Option mit der OPi ausgeschaltet wird.
Nun nimmt man die SD-Karte heraus oder bootet den OPi einfach testweise neu mit noch eingesteckter SD-Karte. In diesem Fall bootet der OPi von der SD-Karte, da diese nun nicht mehr leer ist und ein vollständiges System enthält.
Zwei weitere Anmerkungen:
Das Script nand-sata-install verarbeitet eine Exclude Liste: Die Datei heißt exclude.txt und befindet sich im Verzeichnis /usr/lib/nand-sata-install.
Falls man zusätzliche Mount-Punkte in der /etc/fstab definiert hatte, fehlen diese in der fstab auf der SD-Karte und müssen neu erzeugt werden, sonst startet iobroker nicht ordnungsgemäß. (Ich habe einen zusätzlichen USB-Stick für History und log eingebunden, den musste ich neu in der fstab eintragen).
Gruss
Stefan
-
Vielen Dank für die ausführliche Erklärung!
Zusätzliche Mount Punkte hätte ich auch, SSD für history.
Gesendet von meinem ZTE A2017G mit Tapatalk
Support us
585
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge