omv webgui causes high load

Okie dokie, so I have been running omv 3.0.82 with 4.9.0 bpo3 kernel (I installed straight from omv iso) for a few days on my older NUC de3815tykhe (that's an intel atom e3815 single core 1.46ghz proc). 4GB RAM, 16GB USB3.0 thumb drive, & seagate sshd 1tb in the available sata 3gbps port

I am running the flash memory plugin and omv-extras, nothing else. NFS/SMB/SSH are enabled. I am the sole user. The load only seems to occur when I am viewing either dashboard or system information main page.

Omv is installed on a slightly older thumbdrive (kingston 100g3) via usb3. Someone had suggested to me to try another drive, one is on the way but I just have a funny feeling I may be encountering this problems even with a better/newer thumb drive.

I tried lowering the number of fpm servers available in php5-fpm pools.d but it didn't seem to improve much. Also attempted to enable opcache but does not seem to have helped either. Reverted those changes.

Zitat von rsyslogd

monit[1218]: 'openmediavault.local' loadavg(1min) of 2.5 matches resource limit [loadavg(1min)>2.0]

Any thoughts?

Also let me know if I left out any important information. Thanks!

Any ideas here? Switching to a new/better USB doesn't seem to have helped, I'm not sure going from MLC to SLC is going to have any effect.

After updating from 0.82 to 0.83 I notice I can view the dashboard without incurring load, but the box becomes quite loaded down viewing the "top" output on the main "system information" page. I really don't think the box is so underpowered as to cripple under the webgui..

Oh I guess I should note that the box doesn't become unusable by any means, I can pull up an ssh session and do what I like, even the webui responds fine, might be a few hundred ms slower but it's not *really* an issue per se- just making the jump from an rpi to this particular box, I wouldn't expect these kind of problems on the NUC where there were none on the rpi- granted the rpi has 3 more cores. I will install htop and have a look around to see whats going on next time it becomes loaded down.

Another very odd observation is that it's not always the case that visiting "system information" loads the box down. Sometimes I can have that page up for a few hours without issue, other times I pull it up and the load climbs immediately to 2+ which as I say I don't believe to be great for a single core machine.

Will report back in a few hours, hopefully. Thanks for the response @The Master

well, I'm stumped here, as I already tried addressing the fpm pool configurations, and opcode caching didn't seem to have much effect (if any).

Ok so I have been looking into this a little more. I will try cracking open some of the files in the webui and see what I can see, maybe do a little unit testing or something.

I am going to grab iotop and see if it's not something showing up there, but the FPM logfile is (basically) empty.

Just trying to grasp what's happening, looking at htop last night I noticed one openmediavault-webui FPM child consuming 92% of the CPU for a split second, so I'm beginning to suspect there's something funky with the "top" output that's displayed in a few places in the webui. Specifically maybe some bit of code that's been written inefficiently, but not causing problems on sufficiently powerful machines (this being a 1.46ghz single core proc no hyperthreading)

I changed nginx worker processes from 4 to 1 to reflect the number of cores available on my box, this seems to have made things a bit more stable (ie. I have to refresh the dashboard or sysinfo page a few times before it will begin to load down, instead of on the first try). I also note that since making this change the load has not risen above 2.20 whereas prior I had seen it run as high as 3.5 with 0 active nfs/smb/ssh connections. (Those are really the only services running on the box besides the OMV system itself, monit etc)

Any thoughts or suggestions are appreciated! I will post my findings. I dunno if the dev for the UI is around here very often.

UPDATE: iotop shows nothing, which really isn't much surprise. Tommorow afternoon I will have a look at some PHP

I'm a little frustrated because my assumption is that the webui is quite lightweight. Unless there is a silly loop or something in the PHP, I really don't see what could be causing this issue.

while I have not had time to look at the underlying code in the UI, this issue seems to have resolved itself... Strange!

Cheers.

So changing the cpu governor from conservative/ondemand to performance seems to have helped greatly. I didn't realize this cpu steps from 500mhz to the advertised 1.4ghz, making it essentially an RPI/3 with 3 less cores.