For years, I’ve used it in relative term. When a high number is shown and the system is still responsive, I set that as normal in mind. But that can’t be right. That is got to be a more scientific way of explaining the numbers. Turns out the answer is right in the man page of uptime.
System load averages is the average number of processes that are either in a runnable or uninterruptable state. A process in a runnable state is either using the CPU or waiting to use the CPU. A process in un‐ interruptable state is waiting for some I/O access, eg waiting for disk. The averages are taken over the three time intervals. Load averages are not normalized for the number of CPUs in a system, so a load aver‐ age of 1 means a single CPU system is loaded all the time while on a 4 CPU system it means it was idle 75% of the time.
On a generic workload, let’s simplify the calculation and assume load averages is computed based solely on CPU usage. On a single core system, load averages of 1 means it’s completely busy with that 1 process for the past period of time. On a 16-core system, a load average of 16 the performance expectation should be the same. When interpreting the numbers on a monitoring system or setting up thresholds, we can divide the result by number of cores and multiple it with 100%.
Load averages is actually influenced not just by CPU. IO, network busyness, interrupts, or any other busy resource that prevents processes from completing all contribute. A process can be busy waiting for other resources to return. On some VM, even the random number pool can put the CPU on wait.
That said, load averages is a fairly holistic assessment of how busy a system is.
Red Hat backports fixes and keep package versions as they are. At times, security scanners are not smart enough to know that. They’d complain the packages are out of date. Making it worse, apache 2.2 has reached EOL since 2018. And even though openssh is now on version 8.2, one will still find version 5.3 on EL6 systems.
Upgrading EL is not an easy task like Ubuntu. One will most likely need to build a new system and migrate things over. If that is an issue for you, install my repo and yum-plugin-priorities. Then install or update httpd-2.2.34 with yum.
While this gives you the very last version of apache 2.2, you may be asked to upgrade to apache 2.4. That’s a different game. IUS and SCL offer apache 2.4. Problem is, IUS’s apache does not work with php in the same repo. Their php are built to work with apache 2.2. So as Remi’s. SCL’s httpd24 and php work together, but they put files under a completely different location. And they stop making php packages at version 7.0, which is EOL.
It’s a mess. Migrate to FPM if you can.
Use the packages at your own risk. I cannot promise future updates. Your best option is to migrate to newer OS and rely on updates from the official distro.
I usually don’t care much about RDP version, as long as I can see the remote desktop clearly. I usually set the resolution to a small one with a lower color depth (15-bit). Recently, I realize RDP has been advanced quite a bit. I can get much better remote display quality. Below is a comparison of several protocols supported by Remmina.