Shulou(Shulou.com)06/01 Report--

This article mainly shows you "the reason why slow disk will lead to soaring Linux load". The content is easy to understand and clear. I hope it can help you solve your doubts. Let me lead you to study and learn this article "the reason why slow disk will lead Linux load to soar".

I. the difference between CPU utilization rate and load rate

To distinguish between CPU load and CPU utilization, they are two different concepts, but their information can be displayed in the same top command. CPU utilization shows the percentage of CPU occupied by the program in real time during operation, which is the statistics of CPU usage in a period of time. Through this indicator, you can see that CPU is occupied in a certain period of time. If the occupied time is very high, then you need to consider whether CPU has been overloaded. The CPU load displays statistics about the total number of processes that CPU is working on and waiting for CPU to process over a period of time, that is, statistics on the length of queues used by CPU.

High CPU utilization does not necessarily mean that the load is high, it may be a CPU-intensive task. Will there be a high CPU when the utilization rate of Load Average is low? If you understand the occupancy time and usage time, you can know that after CPU allocates time slices, whether it is used or not is entirely up to the user, so it is entirely possible to have low utilization and high Load Average. In addition, IO devices may also cause high CPU load.

From this point of view, only from the utilization rate of CPU to judge whether CPU is in a state of overload is not enough, must be combined with Load Average to look at the overall use of CPU. There is an example on the Internet to illustrate the difference between the two: in a public telephone booth, one person is on the phone, four people are waiting, and each person is limited to using the phone for one minute. If someone doesn't finish the call within a minute, they can only hang up the phone and wait in line for the next round. The phone here is the equivalent of CPU, and the number of people who are or are waiting for a call is equivalent to the number of tasks. In the course of using the telephone booth, some people will definitely leave after making a call, some people will choose to queue again without finishing the call, and there will be new people queuing here. The change in the number of people is equivalent to the increase or decrease in the number of tasks. In order to count the average load, we counted the number of people every 5 seconds, and averaged the statistics at the 1st, 5th and 15th minutes, thus forming the average load of the 1st, 5th and 15th minutes. Some people pick up the phone and call for one minute, while others may be looking for the phone number in the first 30 seconds, or hesitate to call, and then make a real phone call in the next 30 seconds. If we think of the phone as a CPU and the number of people as a task, we say that the CPU utilization of the previous person (task) is high and the CPU utilization of the latter person (task) is low. Of course, CPU doesn't work in the first 30 seconds and rest in the last 30 seconds. CPU is working all the time. It's just that some programs involve a large number of calculations, so the CPU utilization rate is high, while some programs involve few calculations, so the CPU utilization rate is naturally low. However, no matter whether the utilization of CPU is high or low, it has nothing to do with how many tasks are queued behind.

Both the number of CPU and the number of CPU cores (that is, kernels) affect the CPU load because tasks are ultimately assigned to the CPU core to handle. Two CPU blocks are better than one CPU, and dual cores are better than single cores. Therefore, we need to keep in mind that apart from the differences in CPU performance, CPU load is calculated based on the number of kernels, that is, "how many cores there are, that is, how much load there is". For example, it is best not to exceed 100% per core, that is, the load is 1.00, and so on.

There is a / proc directory in Linux, which stores the virtual mapping of the current running system, and one of the files is cpuinfo, which stores the information of CPU. The / proc/cpuinfo file displays information in paragraphs by logical CPU rather than the real CPU, with each logical CPU's information occupying a paragraph, with the first logical CPU logo starting at 0.

$cat / proc/cpuinfo processor: 0vendor_id: GenuineIntelcpu family: 6model: 63model name: Intel (R) Xeon (R) CPU E5-2630 v3 @ 2.40GHzstepping: 2microcode: 0x36cpu MHz: 2399.998cache size: 20480 KBphysical id: 0siblings: 2core id: 0cpu cores: 2apicid: 0initial apicid: 0fpu : yesfpu_exception: yescpuid level: 15wp: yesflags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr .bogomips: 4799.99clflush size: 64cache_alignment: 64address sizes: 42 bits physical 48 bits virtualpower management:

To understand the CPU information in this file, there are several related concepts to know, such as: processor represents the identity of the logical CPU, model name represents the model information of the real CPU, physical id represents the real CPU and logo, cpu cores represents the number of cores of the real CPU, and so on.

Description of logical CPU: today's servers generally use "Hyper-Threading" (HT) technology to improve the performance of CPU. Hyper-threading technology is that a CPU executes multiple programs at the same time while sharing resources in a CPU. In theory, it is like two CPU executing two threads at the same time. Although hyper-threading technology can execute two threads at the same time, it is not like two real CPU, each CPU has independent resources. When both threads need a resource at the same time, one of them temporarily stops and gives up the resource until the resource is idle. Therefore, the performance of hyperthreading is not equal to the performance of two CPU. CPU with hyper-threading technology has some other limitations.

II. The calculation method of CPU load rate

The concept of Load average is derived from the UNIX system, although the formula is different, but it is used to measure the number of processes that are using CPU and the number of processes waiting for CPU, in a word, the number of runable processes. Therefore, Load average can be used as a reference indicator of CPU bottleneck. If it is greater than the number of CPU, CPU may not be enough.

However, there is a difference in Linux!

The load average on Linux includes not only the number of processes that are using CPU and the number of processes waiting for CPU, but also the number of uninterruptible sleep processes. Usually when waiting for IO devices, waiting for the network, the process will be in the uninterruptible sleep state. The logic of Linux designers is that uninterruptible sleep should be short-lived and will soon be up and running, so it is equated with runnable. However, uninterruptible sleep is sleep no matter how short it is, not to mention that in the real world, uninterruptible sleep may not be very short, a large number of or long-term uninterruptible sleep usually means that IO devices encounter bottlenecks. As we all know, processes in sleep state do not need CPU, and even if all CPU are idle, processes in sleep cannot run, so the number of sleep processes is absolutely not suitable to be used as an indicator of CPU load. Linux's practice of counting uninterruptible sleep processes into load average directly subverts the original meaning of load average. So on Linux systems, load average is basically useless, because you don't know what it means. When you see a high load average, you don't know whether there are too many runnable processes or too many uninterruptible sleep processes, so you can't tell whether the CPU is not enough or the IO device has a bottleneck.

On the other hand, it can explain why the CPU load soars when the disk is slow (when a large number of disks are used). Basically, when I encounter a high CPU load, there are two situations: the CPU itself handles too many tasks, coupled with the high load caused by soft interrupts and context switching too frequently; and the disk is too slow, which leads to too much uninterruptible sleep and high CPU load.

These are all the contents of the article "slow disk will lead to soaring Linux load". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.