Orange Pi Plus 2e
-
Habe jetzt mal meinen Reserve-OPi etwas unter Stress gesetzt:
root@opi2e_reserve:~# sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) 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: 107.1690s total number of events: 10000 total time taken by event execution: 428.6157 per-request statistics: min: 41.97ms avg: 42.86ms max: 62.63ms approx. 95 percentile: 45.35ms Threads fairness: events (avg/stddev): 2500.0000/0.71 execution time (avg/stddev): 107.1539/0.01 root@opi2e_reserve:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 18:04:29: 1296MHz 3.68 74% 0% 74% 0% 0% 0% 49.6°C 0/9^C 18:04:34: 1296MHz 3.38 0% 0% 0% 0% 0% 0% 48.5°C 0/9^CBetrieben mit dem o.g. Netzteil und einem provisorischen Inbetriebnahmekühlkörper. Läuft stabil durch.
Jetzt läuft gerade ein zehnmal solanger Test
-
Der längere Test ist jetzt auch durchgelaufen:
root@opi2e_reserve:~# sysbench --test=cpu --cpu-max-prime=200000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) 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: 200000 Test execution summary: total time: 2998.5967s total number of events: 10000 total time taken by event execution: 11991.7728 per-request statistics: min: 1092.78ms avg: 1199.18ms max: 1327.39ms approx. 95 percentile: 1283.16ms Threads fairness: events (avg/stddev): 2500.0000/1.00 execution time (avg/stddev): 2997.9432/0.38 root@opi2e_reserve:~#Stabil überstanden und läuft noch immer stabil.
-
Hallo,
nachdem ich jetzt mehr logge und auch besser beobachte, tippe ich doch eher auf ein schleichendes Speicherproblem.
Hier mal die Grafik von opi:
Und hier der aktuelle Verbrauch der einzelnen Prozesse:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1188 root 20 0 187576 85664 17332 R 25.2 4.2 134:52.60 iobroker.js-con
817 mysql 20 0 644716 81760 11988 S 0.0 4.0 10:28.31 mysqld
1383 root 20 0 166768 67008 16956 R 3.3 3.2 34:13.80 io.javascript.0
1210 root 20 0 153848 53724 16940 S 0.3 2.6 3:18.22 io.admin.0
1411 root 20 0 147372 48972 17592 S 0.0 2.4 2:48.42 io.telegram.0
1245 root 20 0 147004 48924 17808 S 3.6 2.4 53:51.94 io.sql.0
1263 root 20 0 145324 44772 16984 S 0.3 2.2 7:41.39 io.web.0
1614 root 20 0 134640 44288 17064 S 0.0 2.1 4:22.30 io.opi.0
564 root 20 0 362204 44044 9628 S 0.3 2.1 3:34.16 java
Mal schauen, wie sich das so entwicklet und wann es wieder kracht.
Gruß
Holger
-
Hallo,
kann mir das jemand erklären?
Um 9:10 startetet das Backup vom Backitup Adapter. Wird da ggf der Speicher nicht mehr freigegeben? In der Job Liste sehe ich das aber nicht.
top - 11:22:50 up 1 day, 1:46, 1 user, load average: 0.15, 0.21, 0.21
Tasks: 131 total, 1 running, 83 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.0 us, 1.2 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 2062388 total, 519056 free, 688624 used, 854708 buff/cache
KiB Swap: 131068 total, 131068 free, 0 used. 1301832 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1188 root 20 0 181016 92212 17332 S 7.3 4.5 149:20.92 iobroker.js-con
817 mysql 20 0 644716 81860 11988 S 0.3 4.0 11:36.41 mysqld
1383 root 20 0 170864 72328 16956 S 2.0 3.5 37:50.45 io.javascript.0
1210 root 20 0 158248 59356 16940 S 0.0 2.9 4:14.57 io.admin.0
1245 root 20 0 147004 49848 17808 S 2.0 2.4 60:40.29 io.sql.0
1411 root 20 0 144300 46224 17592 S 0.0 2.2 3:04.86 io.telegram.0
1614 root 20 0 135664 45004 17064 S 0.0 2.2 4:49.12 io.opi.0
1263 root 20 0 144300 44164 16984 S 0.3 2.1 8:57.64 io.web.0
Danke,
Holger
-
Sorry, kann ich leider nichts dazu sagen. Ich mache mein Backup über ein shellscript, welches ioBroker backup und Rsysnc nutzt. Nur das Aufrufen des shellscripts geschieht mit js script, sozusagen statt cron.
Auf meinem piVCCU-opt mache ich backup mit schellscript über die piVCCU Backup-Funktion, rsync und cron.
Und leider habe ich keine so schönen Charts wie Du.
Du kannst ja mal ein paar Backups provozieren und dann beobachten, aber da bist Du sicher schon dran.
-
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
