If I have a process that is running 100 percent (cpu) on a server that has 24 processors, is my cpu utilization 100 percent or is it 100 percent / 24 ?


$ cat /proc/cpuinfo | grep processor | wc -l
24

AND

$ top -bn 1
top - 15:21:46 up 768 days, 18:54, 2 users, load average: 1.18, 1.05, 1.04
Tasks: 336 total, 2 running, 334 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.2 us, 4.9 sy, 0.0 ni, 91.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 65761736 total, 21233600 free, 22230472 used, 22297664 buff/cache
KiB Swap: 4194300 total, 4180908 free, 13392 used. 39833456 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3069 root 20 0 9.857g 9.598g 8440 R 100.0 15.3 2:07.00 mongod


Thanks!

"Traditionally", it would not be considered running at 100% because you still have 23 more processors that could be doing work. (A nice sitation to be in, IMHO.) You just have a process that wasn't written to be aware of other CPUs and take advantage of them and it's monopolizing one of your processors.

You should be able to comfortably sustain a load of "N" where N=#cpus. Anything above that means there are processes waiting for a CPU. (In the olden days, we'd say there were hamsters waiting for their turn on the wheel.)

HTH...

1 members found this post helpful.

Thanks for answer. Let's say this mongod exceeds the single cpu's limit, let's say it's twice what cpu could handle. Would I likely see something like this:

$ top -bn 1
.
.
.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3069 root 20 0 9.857g 9.598g 8440 R 100.0 15.3 2:07.00 mongod
3069 root 20 0 9.857g 9.598g 8440 R 100.0 15.3 2:07.00 mongod

Maybe the PID is an indicator of one process spread out over multiple cpus

I would not expect to see something like that unless the process is doing a heck of a lot of forking, but then I would expect to see the load spread out over most of the processors. The most processor a single thread program can use is 100% of one processor. The situation suggested in your last posting could arise if the same program was fired up as several processes each running a copy of the CPU hog.

1 members found this post helpful.

dmidecode --type processor

# dmidecode 2.12
SMBIOS 2.7 present.

Handle 0x0401, DMI type 4, 26 bytes
Processor Information
Socket Designation: CPU 1
Type: Central Processor
Family: Other
Manufacturer: Intel
ID: F2 06 03 00 FF FB 89 17
Version: Not Specified
Voltage: Unknown
External Clock: Unknown
Max Speed: 2400 MHz
Current Speed: 2400 MHz
Status: Populated, Enabled
Upgrade: Other

Great write-up on a number of ways to extract data from Linux - https://www.tecmint.com/check-linux-cpu-information/

Also, install Monitorix on the system and view processing every few minutes on a webpage.

top -n 1 | grep -i ^cpu (by changing top -d 3 | grep -i ^cpu is another)

T

1 members found this post helpful.

No, only one process, no forks.

Or, if a process is running really busy, it grabs the one cpu and simply slows down, in other words, it wants 101 percent, but it only gets 100 percent. If that is the case, may explain why some of our processes seem slow, slow as in sluggish to reload configs and rules (this is IDS).

Interesting, and thank you.

Here is example of IDS (Intrustion Detection) app called Suricata, top shows this:

31736 root 20 0 7421732 6.768g 445700 S 124.4 5.4 10956:30 Suricata-Main

Looks like after it hits 100 it must load balance to another cpu, doesn't say which. By that logic, at 24 cpus on this server, utilization could go to 2400 percent.

I have included an image for your review.

Monitorix gives the user the ability to view the history of the processor(s) among other things, I have Cloud and external sites presenting this information.

It is pretty nice and can be installed in almost any Linux/Unix System.

T

Attached Thumbnails

   

This is a large part of the reason we now have large numbers of "CPUs" in our systems - it all got too hard to keep up with Moore's Law and grow the CPU. Easier to go sideways than up. But that meant code had to become multi-processor aware and multi-threaded to use it all efficiently.

As you've found "top" shows non-normalised numbers - but you'll never get near 2400% as the overheads to manage that multi-threading grow exponentially, for both the application and the operating system.