Strom sparen mit powertop / Stromverbrauch von UnRaid verbessern


Recommended Posts

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:

 

  • Like 1
Link to comment

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:

image.png.aa062c6ac01b6862d3b0bfd0daf1635c.png

 

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.

Link to comment
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 [email protected]
Password:
Last login: Sat Oct  8 17:36:23 2022 from 192.168.178.88
Linux 5.19.14-Unraid.
[email protected]:~# reboot

Broadcast message from [email protected] (pts/0) (Sat Oct  8 17:41:02 2022):

The system is going down for reboot NOW!
[email protected]:~# exit
logout
Connection to tower closed.
PS C:\Users\Marc> ssh [email protected]
Password:
Linux 5.19.14-Unraid.
[email protected]:~# pgrep -af emhttp
1833 /usr/local/sbin/emhttpd
[email protected]:~# # now I will open the WebGUI
[email protected]:~# # login page
[email protected]:~# pgrep -af emhttp
1833 /usr/local/sbin/emhttpd
[email protected]:~# # after login
[email protected]:~# # main page has loaded
[email protected]:~# 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
[email protected]:~# # I closed the WebGUI, now
[email protected]:~# 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
[email protected]:~# # let's kill the PHP scripts
[email protected]:~# pkill -cf /usr/bin/php
4
[email protected]:~# pgrep -af emhttp
1833 /usr/local/sbin/emhttpd
2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load
[email protected]:~# # open the WebGUI again
[email protected]:~# pgrep -af emhttp
1833 /usr/local/sbin/emhttpd
2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load
[email protected]:~# # open the dashboard
[email protected]:~# 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
[email protected]:~# # close the WebGUI again
[email protected]:~# 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
[email protected]:~# # kill php scripts again
[email protected]:~# pkill -cf /usr/bin/php
5
[email protected]:~# pgrep -af emhttp
1833 /usr/local/sbin/emhttpd
2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load
[email protected]:~# # open the WebGUI again
[email protected]:~# pgrep -af emhttp
1833 /usr/local/sbin/emhttpd
2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load
[email protected]:~# # open dashboard
[email protected]:~# 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
[email protected]:~# # open all menu entries and close the WebGUI
[email protected]:~# pgrep -af emhttp
1833 /usr/local/sbin/emhttpd
2863 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load
[email protected]:~# # power consumption is absolutely constant as it was in Unraid 6.9.2
[email protected]:~#

 

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:

[email protected]:~# 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.

 

Link to comment
5 hours ago, ich777 said:

Reden wir von diesen kleinen ausschlögen oder von was anderem?

Bei mir schaut, das im Idle so aus:

1577288668_2022-10-08Idle.thumb.jpg.4875c0a011c033a3a2e57eb17c236df5.jpg

 

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 by Enks
Link to comment
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.

Link to comment
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:

2101592096_2022-10-08Idlenachkill.thumb.jpg.df01c4dcca6ff68c61b81c209fe75e02.jpg

 

Auch die "baseline" ist leicht gesunken

Link to comment
  • 4 weeks later...
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 by Enks
Link to comment

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.

 

 

Link to comment
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.

Link to comment
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:

 

[email protected]:~# pgrep -af http
2839 /usr/local/sbin/emhttpd
[email protected]:~# 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

 

  • Thanks 1
Link to comment
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.
Powertop.thumb.png.e026de119465ba350fd9a800906c7bfc.png

Hallo,
Welche 6port Marvel Karte hast du eingesetzt?


Gesendet von iPhone mit Tapatalk
Link to comment

Ich habe jetzt Unraid 6.11.2 installiert und nach der Eingabe von powertop --auto-tune erhalte ich folgendes:

 

[email protected]:~# 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:

 

image.png.3e05445c3edbbe74123b86e80050cae1.png

 

Ich habe auch einen weiteren Reboot gemacht, aber keine Veränderung.

Link to comment

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

 

image.png.8393ed962a6122c352302b98e853f80c.png

 

 

Mit diesem Setup und Zustand komm ich auf 22W idle. Leider geht mein Package nicht tiefer als in C3

 

image.png.b8f3c3a4fa8ff7456dc36de7a1e98fea.png

 

image.png.3fcae9251ec2d2254c9aafab161e68ab.png

 

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 by teuflor
Link to comment

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.

 

1294191332_Bildschirmfoto2022-11-09um13_07_32.thumb.png.f4de7285d8874f613df8fb28c9a16e64.png

 

 

  • Thanks 1
Link to comment
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.

 

1294191332_Bildschirmfoto2022-11-09um13_07_32.thumb.png.f4de7285d8874f613df8fb28c9a16e64.png

 

 

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 by teuflor
Link to comment
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.

  • Thanks 1
Link to comment
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

 

image.png.0ac18961644e4dae42cd52a387bdaac7.png

 

 

Link to comment
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...

  • Like 1
Link to comment
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 by MPC561
Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.