Long waiting time after setting an option (save, apply, yes) in OMV web GUI in Mozilla Firefox

  • Hi everybody,


    I am experiencing very long waiting / response times (about 15 min) of the OMV web gui to come back after changing an option and clicking "save, apply, yes" in the web gui.

    My Buffalo Linkstation Duo WXL NAS (2x 2 TB, about 7 years old, 128 MB RAM, ARMv5 ) surely isn't very fast, but this seems odd. Is it an issue with Debian, OMV, my Mozilla Firefox or anything else?

    The NAS is connected via LAN to a router with DHCP, although it always gets assigned the same IP address.


    After one of the two HDDs died some time ago, I decided to:

    - installed a new NAS-suitable HDD (4 TB, as this is the minimum size to come with rotational vibration sensors) with proper partitioning scheme according to the "standard Buffalo scheme" (4 partitions and unpartitioned rest: /boot, /root, swap, / and the rest is for RAID 1 with the other old HDD, shall get partitioned during RAID 1 setup),

    - installed a stable Debian 10 armel kirkwood (4.19.0-9 marvell kernel, per network-console) onto this new HDD

    - installed OMV 5.4.6-1 (usul) and OMV-extras

    - did some basic configuration in the web gui


    So the NAS has 1x 2TB and 1x 4TB now (RAID 1 planned, 2 TB of the new HDD will remain unused until the other old HDD gets exchanged, might be soon)

    Would be glad for any purposeful info or tips...

  • Longish waits on saving and applying changes are not uncommon on OMV 5. But 15 minutes is excessive.


    Does your machine really have only 128MB of RAM or is that a typo? If that's all you have I would imagine that the machine spends a lot of time in swap and this can greatly slow things down.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • Quote

    Does your machine really have only 128MB of RAM or is that a typo? If that's all you have I would imagine that the machine spends a lot of time in swap and this can greatly slow things down.

    Yes, it has only 128 MB. I also experienced a problem with my initial ramdisk, as it was set to 13MB by /etc/initramfs-tools.conf (default is 10%), but at the same time systemd required at least 16MB free on /run.

    When working as root in a terminal I don't have to wait very long for apt updating, installing or getting any feedback messages though. Furthermore, working in swap should be a different process not really connected to sending messages / packets to the OMV web gui. Therefore, I somehow guess that it is an issue of network packet transfer between debian, OMV and my browser web guis...?

  • I think the problem is that the Salt stuff that runs when changes are made and applied is a huge resource hog.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

  • Those old armel cpus are so slow that they shouldn't be used for OMV 5.x and newer. salt is definitely going to take forever with the resources of that system.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Thanks for your infos, I tried to inform myself a little about Salt (or SaltStack). Is there a way to run OMV 5.x without Salt, or a different configuration of it, as it seems to be a service to manage Server stacks (not needed for just one home server)?

    Would the situation / performance be better with OMV 4.x? Is there a way to use this older OMV version or a version without Salt with Debian 10?

  • Is there a way to run OMV 5.x without Salt,

    No.


    as it seems to be a service to manage Server stacks (not needed for just one home server)?

    While it can be used that way, it can also be used to manage configuration on a single server. It is not running in master/slave mode like you probably that it is capable of.


    Would the situation / performance be better with OMV 4.x?

    Yes because it is using shell scripts to configure things.

    Is there a way to use this older OMV version or a version without Salt with Debian 10?

    No. OMV releases are tightly locked to the version of Debian they require.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Thank you for the info.

    So if possible, it would need a Debian 10 / OMV 5.x version for older hardware home servers that uses shell scripts instead of the Salt services like in OMV 4.x. That would be nice to have...

  • t would need a Debian 10 / OMV 5.x version for older hardware home servers that uses shell scripts instead of the Salt services like in OMV 4.x.

    That would require reverting ALL of the saltstack changes done to OMV 5.x and the plugins. Basically, you would be going back to OMV 4.x. This is not going to happen. At some point, old, slow hardware just needs to be replaced. Even Windows does this.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!