- Solved
- Minor
Found the problem. Read the first comment of this bug report.
TL;DR
Multiple users reported spikes in their power consumption after updating to Unraid 6.10 and this is still present in Unraid 6.11:
https://forums.unraid.net/topic/105909-mein-10-zoll-server/?do=findComment&comment=1143526
https://forums.unraid.net/topic/105909-mein-10-zoll-server/?do=findComment&comment=1176094
In Unraid 6.9 the power consumption was relatively stable. Example:
I will try to monitor the processes on my test server, which uses Unraid 6.11.1. Hopefully I can find out which process causes those spikes. I will update this bug report later...
EDIT: This is what came in my mind:
- close all web GUI windows
- connect through SSH and execute this:
watch -d "ps -Ao comm,pid,pcpu --sort=-pcpu | head -n 12"
- watch parallely power consumption...
EDIT2:
Every couple of minutes I was able to capture an "rpcd_lsad" process:
Compared with the default situation:
In addition you can see that "emhttpd", "update_3", "file_manager", "device_list" and "parity_list" are constantly producing load.
1.) The "emhttpd" process should be the main webserver process to deliver the Unraid WebGUI. Any possible improvements needed to be checked by @limetech.
2.) The "update_3" process is an PHP script:
# pgrep -af update_3 15795 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3
It seems constantly logging network status from multiple network devices and ports. Is it really needed to do this with PHP parser overhead? And is it necessary to run this all the time?
3.) The "file_manager" process is caused through the new Dynamix File Manager Plugin of @bonienl. I wonder why its active although I do not have the GUI open?! After uninstalling it disappears (logic), after installing it's not present (?!), but after opening a dir and closing the GUI it stays present:
# pgrep -af file_manager 24508 /usr/bin/php -q /usr/local/emhttp/plugins/dynamix.file.manager/nchan/file_manager
I think it should auto-exit after the GUI has been closed.
4.) The "rpcd_lsad" process is related to SMB:
# find / -xdev -name rpcd_lsad /usr/libexec/samba/rpcd_lsad
Not sure why it is starting and stopping every couple of minutes as I'm not using Active Directory?!
5.) The "parity_list" and "device_list" PHP scripts are really necessary while the GUI is closed?!
root@Tower:~# pgrep -af parity_list 2893 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/parity_list root@Tower:~# pgrep -af device_list 2889 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/device_list
6.) The bash script "disk_load" is constantly writing disk stats to an ini file. Is it really needed although the GUI is closed?
root@Tower:~# pgrep -af disk_load 2891 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load
EDIT3:
I deleted the file (test server 
) and checking the syslog proofs that it is executed every minute:
root@Tower:~# rm /usr/libexec/samba/rpcd_lsad root@Tower:~# tail -f /var/log/syslog ... Oct 8 15:12:01 Tower winbindd[2222]: [2022/10/08 15:12:01.690211, 0] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn) Oct 8 15:12:01 Tower winbindd[2222]: open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_REFUSED Oct 8 15:13:01 Tower winbindd[2222]: [2022/10/08 15:13:01.766520, 0] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn) Oct 8 15:13:01 Tower winbindd[2222]: open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_REFUSED Oct 8 15:14:01 Tower winbindd[2222]: [2022/10/08 15:14:01.844427, 0] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn) Oct 8 15:14:01 Tower winbindd[2222]: open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_REFUSED Oct 8 15:14:01 Tower winbindd[2222]: [2022/10/08 15:14:01.861246, 0] ../../source3/winbindd/winbindd_samr.c:71(open_internal_samr_conn) Oct 8 15:14:01 Tower winbindd[2222]: open_internal_samr_conn: Could not connect to samr pipe: NT_STATUS_CONNECTION_REFUSED
EDIT4:
Before disabling SMB:
After disabling SMB (only a small improvement visible):
EDIT5: After killing the "parity_list" and "device_list" processes its still fluctuating, but the overall consumption is reduced:
EDIT6: After killing "update_3"
As you can see the power consumption has become lower, but it's still fluctuating.
EDIT7: After killing all php processes (update_1, update_2, ...) and the bash script /usr/local/emhttp/nchan/disk_load, it looks much more like Unraid 6.9:
In comparison Unraid 6.9 only had the constanly running diskload script:
root@thoth:~# pgrep -af emhttp 7362 /usr/local/sbin/emhttpd 7590 /bin/bash /usr/local/emhttp/webGui/scripts/diskload root@thoth:~# pgrep -af php 11519 php-fpm: master process (/etc/php-fpm/php-fpm.conf)
I will reboot the server and do some more tests, but I think the constantly running PHP-scripts are the reason for the higher power consumption and the spikes (of course the SMB thing has be checked separately).
-
7
