Delay when first accessing OMV UI (and other pages served from the same machine)

    I am running OMV 5 with 12 docker containers and two virtual machines (KVM). None of these containers or instances is particularly busy (most of them are not doing anything, actually), so my CPU usage is below 20% most of the time:



    But whenever I try to access the webpage provided by one of the containers, a vm or even OMV's own UI, I have a delay of between 2 and perhaps 10 seconds until the page loads. During that time, the browser shows "Waiting for ...":



    This delay only happens the first time I access the URL, after that it is fast. Not sure how long I have to wait until it gets slow again, but less than 1-2 hours.


    Could someone give me a hint where/how I can start troubleshooting this. How can I narrow down what is causing this delay? It could have something to do with the network configuration. Since VMs, docker containers and the host itself are showing the same symptoms, I'm guessing it must be the hosts config, but how do I check this?


    Or perhaps I am running out of RAM?



    I read somewhere that almost full RAM is not a bad thing because it means that precious resource is well utilized. But how do I know whether it's getting too tight?


    Or is it related to the more severe issue I'm (sometimes) seeing when trying to login to Cockpit?:



    This TLS handshake problem seems tp be specific to Cockpit and not specific to me as I've seen several reports about it...


    So, where to start?

    Since I didn't know where to start on the software side, I tried adding some RAM (before: 8 GB, now: 24GB) and it looks like it solved the problem of delays. So, after all, the problem turns out to have been rather simple and precisely as I guessed above: what was taking so much time at first call was moving stuff from wherever it was into RAM. This would have been evident to me if I had seen lots of swap usage but I didn't see that. But maybe I wasn't looking properly?


    Anyway, what probably should have alerted me is the orange part of the CPU graph above: it represents the time the CPU spends waiting for som I/O operation to complete. Here is the same diagram before and after adding RAM (at about midnight):



    See how the Wait-IO almost disappears after I added RAM? So, for me this really an interesting lesson in how RAM affects speed. I have no idea to what extent this could have been diagnosed from the information I provided in the OP, but since noone provided any diagnosis, I'm guessing that this is a comples issue so that if you are seeing the same symptoms, your solution may still be different. But I dare say: if you are seeing a lot of Wait IO in your CPU usage, adding RAM is worth a try.


    You probably don't need to triple your RAM, like I did, but it's interesting to see that if you do, Debian will use it for something:



    Not sure how exactly this works, but it's fascinating and a big plus for Linux. Some months ago, I added RAM to my Windows desktop PC and I did *not* see anything like that. I rarely see Windows not using more than 50% of available RAM. So rarely that I was wondering for some time, whether there was something wrong with the RAM or if some setting is preventing Windows from using what it has... Well, to be fair: in order to make this a proper comparison I should run a dozen docker containers and two virtual machines on my desktop. Chances are that memory useage would increase.


    But anyway: I find it interesting how Debian only gradually increased RAM usage over the course of a couple of hours. I like to imagine it like an animal set free from long time captivity: it first has to explore the new space before realizing it is free. Is it really true? Can I go this far? And still further?

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden