​OMV5 on Cubietruck or Raspi 4b: 100% cpu usage (python3) while saving changes in the webfrontend

1. offizieller Beitrag

    Hi all,

    i installed omv4 on a debian 9 - i am using a cubietruck. When i change any configuration in the webfrontend and save it, i am asked to apply the changes. If i do so, i can see the progress bar for about 2-5 seconds - so this is okay for me.


    Beside this, i did a fresh install of debian 10 and omv5 - if i apply my changes here, i see the progress bar for about 30 seconds - which is too bad for me.


    Having a look at top, i can see a 100% cpu usage of the process python3, and the processes of php-fpm are also busy. when the progress bar is finished, the cpu usage normalizes.


    So i thought: okay, the cube is way to old and not sufficient - so i reproduced this issue on a Raspi 4B, which should have enough power to handle omv5.


    But: Same load here, same behaviour of the progress bar. <X


    Any hints or comments?


    Regards,

    Andreas

  • abyss02

    Hat das Label OMV 5.x hinzugefügt.
    • Offizieller Beitrag

    Nothing you can do about it. Saltstack is doing the configuration management and it does a lot more than the old shell scripts. It is processor intensive and is going to be slow on slow systems (yes, an rpi4 is slow compared to newer multi-core i-series Intel chip). The best suggestion I have is to make more changes before clicking apply to minimize the number of times you have to apply.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Offizieller Beitrag

    This is all speculation. I have very limited experience running OMV5 and very limited understanding of salt.


    I suspect this extra processing is the expected behavior. It does discourage exploratory use of OMV. Changes require more time and processing.


    I assume that the reason is that salt, when changes are applied, walk through many (all?) of the settings and installs possible in OMV5 and checks to see if something needs to be done or updated. As I understand it this is a significant amount of processing and it may even include running sudo apt-get multiple times?


    Is a working internet connection now always needed to apply changes in OMV5?


    The benefit, I assume, is that salt automatically handle cascading and recursively interdependent settings, configurations, updates and installs of packages. This may help devepment and make OMV less likely to glitch. The downside is that changes takes longer to apply. And perhaps internet is needed.


    I belive the by default disabled /sharedfolders feature is another example. Changes could take significantly longer to apply if that was still enabled. I assume that the reason was that salt then had to perform various extra tests on the filesystem to verify that it was correctly configured, and that could take time. Filesystems and caches need flushing and comparing and so on.


    It is possible that hardware and a internet connection that previously (OMV4) was marginal now is less than marginal. And for some this may mean that with weak equipment and slow internet OMV is no longer usable in the same way as before.


    It is also possible that you can find new ways to work that means that you don't have to apply changes as often, and that makes it easier to accept that changes may take longer to apply. You simply apply changes less frequently.


    I have seen suggestions, in other salt circles, to setup a local apt cach server to speed up apt-get update. I am not sure if that is needed for me. It might be. Testing will tell...

    • Offizieller Beitrag
    Zitat von Adoby

    I assume that the reason is that salt, when changes are applied, walk through many (all?) of the settings and installs possible in OMV5 and checks to see if something needs to be done or updated. As I understand it this is a significant amount of processing and it may even include running sudo apt-get multiple times?

    Configuration management is not fast but does a better job whether you are using salt, puppet, ansible, whatever. I don't think the speed is bad at all on a recent intel or amd chip. Even arm speed doesn't bother me as long as sharedfolders is disabled but I have been using OMV 5 forever. It is not doing multiple apt-gets. The other problem is salt is even slower from the web interface because php-fpm is monitoring it in almost realtime to display info for the web interface.


    Zitat von Adoby

    Is a working internet connection now always needed to apply changes in OMV5?

    No.


    Zitat von Adoby

    The benefit, I assume, is that salt automatically handle cascading and recursively interdependent settings, configurations, updates and installs of packages. This may help devepment and make OMV less likely to glitch. The downside is that changes takes longer to apply.

    Yes


    Zitat von Adoby

    It is also possible that you can find new ways to work that means that you don't have to apply changes as often, and that makes it easier to accept that changes may take longer to apply. You simply apply changes less frequently.

    This is my advice as well.


    Zitat von Adoby

    have seen suggestions, in other salt circles, to setup a local apt cach server to speed up apt-get update. I am not sure if that is needed for me. It might be. Testing will tell...

    OMV's code only does apt-get updates when you tell it to. So, pretty much only when you click Check or Update in the plugin or updates or some omv-extras tabs.

    Interesting, wasn't aware that Salt uses Python. But then again I don't know anything about Salt.


    I'd like to report that I'm finishing up a fun little project of installing first Debian and now OMV on an old NAS with a single ARMv5 800MHz processor and only 256MB of RAM! It was quite a project to learn how the bootloader works and to work around some problems accessing the installer via SSH. I committed to installing the only image that worked, an old Debian Jessie release. Once on the disk, I upgraded Jessie -> Stretch -> Buster. Then I finally installed OMV, and I've been configuring it. Looks like it's going to work a treat, but applying configuration changes definitely takes a *long* times. At first I thought it was constantly going to be grinding away at a python3 script w/ 100% CPU nonstop 24x7, but then I discovered this thread and learned that it's related to salt. And after letting it sit for 30-45 minutes it does indeed finish eventually and the processor settles down to almost 0, with a few php-fpm brief spikes. So to anybody who Googles this thread, patience is a virtue, and OMV is a fantastic product, even for *extremely* limited hardware! The web interface is actually surprisingly responsive, even with all the live AJAXey stuff going on.


    Thanks devs for your amazing work.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden