October 8, 20223 yr 1 hour ago, ich777 said: Habt ihr schon mal versucht im Safe Mode zu booten und dort ein paar stunden zu bleiben ob es dort das selbe ist? Das haben auch meine beiden Testserver. Die sind quasi nackt. Ich versuche mal die Tage zu monitoren ob Prozesse regelmäßig auftauchen und die CPU mehr fordern als üblich. Ich habe daraus schon mal einen Bug Report gemacht:
October 8, 20223 yr Grobes Zwischenfazit nach einer längeren Analyse: Unraid 6.11.1 hat eine Hand voll PHP- und Bash-Skripte, die konstant laufen, alle 1 bis 2 Sekunden irgendwas auslesen und manche davon aktualisieren auch Dateiinhalte. Nachdem ich die alle gekillt habe, sieht der Verbrauch schon deutlich stabiler aus: In Unraid 6.9.2 gab es die ganzen PHP-Skripte nicht, daher gehe ich davon aus, dass die die Ursache für den höheren und schwankenden Verbrauch sind.
October 8, 20223 yr 10 minutes ago, mgutt said: In Unraid 6.9.2 gab es die ganzen PHP-Skripte nicht, daher gehe ich davon aus, dass die die Ursache für den höheren und schwankenden Verbrauch sind. Welche skripte genau?
October 8, 20223 yr 58 minutes ago, ich777 said: Welche skripte genau? Hier mal der komplette Verlauf nach einem Neustart, womit ich verbindlich den konstanten Stromverbrauch erreiche und wodurch man die Skripte sehen kann: PS C:\Users\Marc> ssh root@tower Password: Last login: Sat Oct 8 17:36:23 2022 from 192.168.178.88 Linux 5.19.14-Unraid. root@Tower:~# reboot Broadcast message from root@Tower (pts/0) (Sat Oct 8 17:41:02 2022): The system is going down for reboot NOW! root@Tower:~# exit logout Connection to tower closed. PS C:\Users\Marc> ssh root@tower Password: Linux 5.19.14-Unraid. root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd root@Tower:~# # now I will open the WebGUI root@Tower:~# # login page root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd root@Tower:~# # after login root@Tower:~# # main page has loaded root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2857 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/notify_poller 2859 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/session_check 2861 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/device_list 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load 2865 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/parity_list root@Tower:~# # I closed the WebGUI, now root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2857 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/notify_poller 2859 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/session_check 2861 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/device_list 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load 2865 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/parity_list root@Tower:~# # let's kill the PHP scripts root@Tower:~# pkill -cf /usr/bin/php 4 root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load root@Tower:~# # open the WebGUI again root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load root@Tower:~# # open the dashboard root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load 3486 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/wg_poller 3488 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_1 3490 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_2 3492 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3 3494 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/ups_status root@Tower:~# # close the WebGUI again root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load 3486 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/wg_poller 3488 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_1 3490 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_2 3492 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3 3494 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/ups_status root@Tower:~# # kill php scripts again root@Tower:~# pkill -cf /usr/bin/php 5 root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load root@Tower:~# # open the WebGUI again root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load root@Tower:~# # open dashboard root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load 4374 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/ups_status root@Tower:~# # open all menu entries and close the WebGUI root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load root@Tower:~# # power consumption is absolutely constant as it was in Unraid 6.9.2 root@Tower:~# Führt man diese beiden Befehle nach dem Schließen der WebGUI aus, sinkt der Verbrauch und bleibt stabil: pkill -cf /usr/local/emhttp/webGui/nchan rm /var/run/nchan.pid Öffnet man die WebGUI allerdings wieder, werden alle Skripte erneut gestartet und bleiben dann wieder offen: root@Tower:~# pgrep -af emhttp 1833 /usr/local/sbin/emhttpd 2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load 10240 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/notify_poller 10242 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/session_check 10360 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/device_list 10364 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/parity_list 10506 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/wg_poller 10508 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_1 10510 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_2 10512 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3 10514 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/ups_status Das einzige Skript, was sich selbst sauber beendet, wenn das Dashboard verlassen wird, ist /usr/local/emhttp/webGui/nchan/ups_status. Allerdings auch nur dann, wenn man erst mal auf eine andere Seite wie zB die Settings wechselt. Schließt man dagegen den Browser, bleibt auch das Skript für immer offen.
October 8, 20223 yr 5 hours ago, ich777 said: Reden wir von diesen kleinen ausschlögen oder von was anderem? Bei mir schaut, das im Idle so aus: Ich habe aber auch unter Last öfter Ausschläge seit dem Update auf 6.11, die meiner Ansicht nach unter 6.9.2 so nicht auftraten. Mit 6.9.2 hatte ich einen mittleren täglichen Verbrauch von 0,632 kW (Mittelwert aus 26 Tagen) Mit 6.11 habe ich nun einen mittleren täglichen Verbrauch von 0,735 kW (Mittelwert aus 4 Tagen) => Der mittlere tägliche Verbrauch stieg mit dem Update um ca. 100 W. Ich kann mir gut vorstellen, dass diese Differenz durch die Summe dieser auftretenden Ausschläge zustande kommt, da sich ansonsten an meiner Nutzungsweise und Hardware nichts geändert hat. EDIT, der Vollständigkeit halber: Gemessen wird das Unraid System bestehend aus: Gigabyte C246M-WU4 mit i3-9100, 64 Gb ECC Ram (2 Riegel), 2x NVME, 5 HDDs und 1x SATA-SSD. Netzteil ist ein Corsair RM550x 550W (2021) + USV (APC Backp-UPS Pro 550) Edited October 8, 20223 yr by Enks
October 8, 20223 yr 1 minute ago, Enks said: Bei mir schaut, das im Idle so aus: Öffne das WebTerminal und schließe alle sonstigen WebGUI Fenster. Nun führe das aus: pkill -cf /usr/local/emhttp/webGui/nchan rm /var/run/nchan.pid Schließe nun auch das WebTerminal und prüfe deinen Verbrauch.
October 8, 20223 yr 51 minutes ago, mgutt said: Schließt man dagegen den Browser, bleibt auch das Skript für immer offen. Schreib das mal in deinen Bug thread und markier @bonienl. 12 minutes ago, Enks said: 6.11 Mit 6.10 wurde auf nchan umgestellt.
October 8, 20223 yr 1 hour ago, mgutt said: Öffne das WebTerminal und schließe alle sonstigen WebGUI Fenster. Nun führe das aus: pkill -cf /usr/local/emhttp/webGui/nchan rm /var/run/nchan.pid Verbrauch wurde auch bei mir um einiges stabiler: Auch die "baseline" ist leicht gesunken
October 9, 20223 yr Da ich ja auch diese Schwankungen von ca. 5 Watt habe, habe ich mal diesen obengenannten Befehl ausgeführt. Der Idle ist nun um 1.5 Watt und die Schwankungen auf 2 Watt gefallen
November 5, 20223 yr On 10/8/2022 at 7:45 PM, Enks said: Verbrauch wurde auch bei mir um einiges stabiler: Hatte jetzt 6.11 einen knappen Monat laufen und bin nun zurück auf 6.9.2. Der Verbrauch war unter 6.11, trotz penibler Ausführung besagter Befehle, einfach zu hoch. Ich kam im Durschnitt auf einen täglichen Verbrauch von 0,72 kW. Unter 6.9.2 liegt der Verbrauch im Durchschnitt lediglich bei 0,62 kW/Tag. Aufs Jahr gesehen wäre das eine Differenz von knap 37 kW. Gibt es schon Erkenntnisse ob in 6.11.2 der Power consumption bug behoben wurde? Edited November 5, 20223 yr by Enks
November 5, 20223 yr Ich bin grad erst auf 6.11.1 gewechselt der Verbrauch ist minimal höher auch bei meiner Konfiguration. Was mich aber freut das mein Parity HDD Bug weg ist. Ich habe meine Fotoalben auf Share mit einer SSD ausgelagert das aber durch die Parity HDD gesichert wurde. Allerdings hatte ich immer das Problem das die Parity Platte nicht in den Spindown gehen wollte obwohl bzw. sehr schneller wieder hoch kam. Das Problem hat sich nach dem Update bei mir erledigt.
November 5, 20223 yr 2 hours ago, Enks said: Gibt es schon Erkenntnisse ob in 6.11.2 der Power consumption bug behoben wurde? probier es doch aus, da es auchkein genereller "bug" ist ... hier hat es sich zum Beispiel nicht verändert, allerdings auch mit anderer Konfiguration und Basis ... da hier 2 dGPU's verbaut sind usw ... sprich, ich war bei ~55 Watt idle und bin bei ~ 55 Watt idle wenn die VM's aus sind.
November 5, 20223 yr 8 hours ago, Enks said: Gibt es schon Erkenntnisse ob in 6.11.2 der Power consumption bug behoben wurde? Keine Änderung. Nach dem Neustart sieht noch alles gut aus, aber sobald man die GUI geöfnet hatte, sind zig Skripte dauerhaft offen: root@Tower:~# pgrep -af http 2839 /usr/local/sbin/emhttpd root@Tower:~# pgrep -af http 2839 /usr/local/sbin/emhttpd 3948 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/notify_poller 3950 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/session_check 3952 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/device_list 3954 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load 3956 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/parity_list 4168 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/wg_poller 4170 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_1 4172 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_2 4174 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3
November 6, 20223 yr So es lag an dem 2 Port JMB , hab von meinem Bruder einen 6 Port Marvel und mit diesem geht die Cpu in die pkg bis C8. Allerdings wudert mich das ich unter Cpu(Os) nur C3 habe , auf Bildern von anderen sehe ich da auch immer bis C10. Ich liege jetzt im Idle bei 19,2-19,8 Watt. Hallo, Welche 6port Marvel Karte hast du eingesetzt?Gesendet von iPhone mit Tapatalk
November 8, 20223 yr Ich habe jetzt Unraid 6.11.2 installiert und nach der Eingabe von powertop --auto-tune erhalte ich folgendes: root@UNRAID012021:~# powertop --auto-tune powertop: /lib64/libncursesw.so.6: no version information available (required by powertop) powertop: /lib64/libtinfo.so.6: no version information available (required by powertop) modprobe cpufreq_stats failed Cannot load from file /var/cache/powertop/saved_results.powertop Cannot load from file /var/cache/powertop/saved_parameters.powertop File will be loaded after taking minimum number of measurement(s) with battery only RAPL device for cpu 0 RAPL device for cpu 0 Devfreq not enabled glob returned GLOB_ABORTED Cannot load from file /var/cache/powertop/saved_parameters.powertop File will be loaded after taking minimum number of measurement(s) with battery only Leaving PowerTOP In dem extra Ordner ist Powertop noch vorhanden: Ich habe auch einen weiteren Reboot gemacht, aber keine Veränderung.
November 8, 20223 yr 2 hours ago, Zip said: erhalte ich folgendes: Alles korrekt und kann ignoriert werden.
November 9, 20223 yr Seit Unraid 6.11.3 ist der Stromkonsum meines ATOM J4105 Servers wieder ca, auf den Wert von 6.10.x zurück. Reduzierung um ca. 1W im Idle. Wollts nur vermelden und fragen ob jemand eine ähnliche Erfahrung gemacht hat mit dem neuen Update. Gruss, Joerg
November 9, 20223 yr Moin Zusammen, ich hab mich in letzter zeit auch hier durch die Threads gearbeitet und versucht meinen Server das Stromsparen beizubringen. Aktuell habe ich folgende Config: M/B: ASRock B365M Pro4 CPU:Intel® Core™ i5-8400 CPU @ 2.80GHz Memory:24 GiB DDR4 (max. installable capacity 64 GiB) ( 3 Riegel) 3 x 120mm Lüfter Mit diesem Setup und Zustand komm ich auf 22W idle. Leider geht mein Package nicht tiefer als in C3 Ich dachte erst, das läge an der 2.5GBit Netzwerkkarte die ich eingebaut hatte. Aber mit der Onboard Intel wars das gleiche Spiel, bzw. hat sich nichts geändert. Im bios hab ich alles von "auto" auf Stromsparmodus etc eingetragen. Die NVME's unterstützen das ganze wohl auch... Ich weis nimma weiter. Jemand ne Idee? Edit: Nach dem Update 6.11.3 bin ich jetzt im Idle auf 28W hoch gegangen. Jetzt geht das Pkg nur noch in C2 und überhaupt nicht mehr in C3... bäh Edit: Mit Powertop --auto-tune komm ich wieder in C3 und 22W Edited November 9, 20223 yr by teuflor
November 9, 20223 yr Ob der Ethernet Controller das problem ist kannst du mit folgendem Kommando checken: lspci -vvvnnPPDq | grep -B 30 ':[[:space:]]ASPM' In meinem Bild sieht man In der vorletzten Zeile bei LnkCtl das ASPM L1 aktiviert ist. Er verhindert also tiefere Sleep States nicht.
November 9, 20223 yr 2 hours ago, MPC561 said: Ob der Ethernet Controller das problem ist kannst du mit folgendem Kommando checken: lspci -vvvnnPPDq | grep -B 30 ':[[:space:]]ASPM' In meinem Bild sieht man In der vorletzten Zeile bei LnkCtl das ASPM L1 aktiviert ist. Er verhindert also tiefere Sleep States nicht. Vielen Dank für den Befehl, Bei mir taucht der Ethernet controller da überhaupt nicht auf... die 2 nvme's unterstützen schon mal ASPM L1 Das iss ne Intel 219i nic. Vielleicht bau ich mal den 2.5gbit nochmal ein und check ob der das kann... 2 hours ago, Towatai said: Teste mal bitte mit Powertop 2.8. 2.8 ?? ich finde nur 2.15 Ich hab langsam die Vermutung das es am krüppligen ASROCK Board liegt. Edited November 9, 20223 yr by teuflor
November 9, 20223 yr 2 minutes ago, teuflor said: Bei mir taucht der Ethernet controller da überhaupt nicht auf... die 2 nvme's unterstützen schon mal ASPM L1 Na das wundert mich jetzt schon. Dann einfach mal nur: lspci -vvvnnPPDq Dann von oben nach unten durchgehen bis du den Ethernet Controller findest, weil da muss er sein, und schauen ob es ein LnKCtl gibt und wenn ja was da steht. Ich "vermute" aber mal dadurch das der bei dem grep ASPM nicht auftaucht das wirklich Ethernet dein Problem ist weil kein ASPM aktiv ist da.
November 9, 20223 yr 3 minutes ago, MPC561 said: Na das wundert mich jetzt schon. Dann einfach mal nur: lspci -vvvnnPPDq Dann von oben nach unten durchgehen bis du den Ethernet Controller findest, weil da muss er sein, und schauen ob es ein LnKCtl gibt und wenn ja was da steht. Ich "vermute" aber mal dadurch das der bei dem grep ASPM nicht auftaucht das wirklich Ethernet dein Problem ist weil kein ASPM aktiv ist da. das wirds wohl wirklich sein... und meine 2.5gbit billige "china" nic wirds bestimmt auch nicht können.. werds mal heute abend umbauen und nochmal testen. Danke schon mal
November 9, 20223 yr 17 minutes ago, teuflor said: joa... muss mal schauen how to ^^ Warum? Das macht doch keinen Sinn eine ältere Version sprich 2.8 zu nehemn statt 2.15, wobei ich sagen muss das 2.15 eigentlich ohne Probleme laufen sollte wobei 2.8 schon Probleme machen kann unter den neueren Unraid versionen bzw. dann gar nicht funktioniert. Dein Problem liegt sicher nicht an PowerTop und @Towatai müsste mir das auch erklären warum er meint das PowerTop 2.8 besser funktioniert...
November 9, 20223 yr 18 minutes ago, teuflor said: mal heute abend umbauen und nochmal testen Vergiss nicht die Onboard Netzwerkgeschichte im Bios zu deaktivieren. PS: Man kann versuchen ASPM zu erzwingen über einen Kernel Parameter. Hab ich aber noch nicht gemacht. Sollte der Kollege @mgutt aber was zu sagen können. Der kann eh, falls ich was falsches gesagt haben sollte, meine Aussagen korrigieren 🙂 Gruss, Joerg Edited November 9, 20223 yr by MPC561
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.