Figuring out CPUs and Sockets - Updated!

Latest response

So a while back I posted this article in our older portal group system. It was fairly popular and generated quite a bit of good conversation. I'm reposting here and have attempted to weave in some of the great comments we received from the Community. As with anything in this exciing world of open source, there are literally dozens of ways to skin this cat. So please read on and let us know if you other options we can share.

I had a recent email from one of my customers. His organization was about ready to go through some licensing true-ups and he was in a bit of a pickle. He had a few 3rd-party products they needed to do some accounting on and each product was licensed using a different model. Sadly they did not have any type of CMDB in place to help (Configuration Management Database - something very handy to have when it comes to looking at your server inventory). I thought back to my years of running a large Enterprise *NIX team and shuddered; easily once every month or so someone came by asking me the exact same questions.

So we worked on a few simple commands that can be used to produce this data. First we tried this:

$ lscpu | grep 'socket'
Core(s) per socket: 2
CPU socket(s): 1

At this command's "core" [ha ha, pun intended] we got exactly what my pal Tom wanted, and then some. Not only can we see how many sockets he was using (which is what he was reporting for) but we also found out how many cores there were in each socket.

Next we tried something that while much less pretty, zeroed in on the exact requirement:

$ cat /proc/cpuinfo | grep "physical id" | sort -u | wc -l
1

This told us exactly how many sockets we had. And then for fun (Tom is nothing if not fun) we wondered how you could account for if something was hyperthreaded or not so he whipped out this:

$ egrep -e "core id" -e ^physical /proc/cpuinfo|xargs -l2 echo|sort -u
physical id : 0 core id : 0
physical id : 0 core id : 1

So Tom went back to work, happy and ready to give his bosses EXACTLY what they needed (he was so happy he had a new scripting project to tinker with). These commands worked from RHEL6 back to RHEL4 so most everyone should be able to use them, So if you're interested in giving these a whirl, there are also a few official knowledge solutions produced by our esteemed Ryan Sawhill you may want to review too:

Check if Server is VM?

dmidecode | grep -i product

        Product Name: VMware Virtual Platform 

Get number of CPU

grep -i "physical id" /proc/cpuinfo | sort -u | wc -l 

dmidecode |grep -i cpu

Socket Designation: CPU1

    Socket Designation: CPU2 
    Socket Designation: CPU3 
    Socket Designation: CPU4 
            CPU.Socket.1 
            CPU.Socket.2 
            CPU.Socket.3 
            CPU.Socket.4 

To check this a few different ways:

Check if HyperThreading is enabled

# of siblings = # of cores 

    cat /proc/cpuinfo |egrep 'sibling|cores' 
    grep -i "processor" /proc/cpuinfo | sort -u | wc -l 

Hyperthreading can be found with lscpu too:

# lscpu | grep -i thread
Thread(s) per core:    2
#cat /proc/cpuinfo | grep "physical id" | sort -u | wc -l
0

But dmidecode still shows sockets:

# dmidecode -t4 | egrep 'Designation|Status'
        Socket Designation: CPU 1
        Status: Populated, Enabled
        Socket Designation: CPU 2
        Status: Populated, Enabled

And far and away the best hidden nugget from the older article was a tool that I use very often here during my day helping support customers: xsos

I use xsos to help look at infomration provided in sosreports, but it has a lot of great uses (like our proc/socket question here). You can get xsos here:

https://github.com/ryran/xsos

Yum repo available for xsos -- a tool for sysadmins

On a machine here in the lab I ran xsos so you can see typical output:

# xsos
OS
  Hostname:  LINUXizTHAawesome
  Distro:    Red Hat Enterprise Linux Workstation release 6.4 (Santiago)
  Kernel:    2.6.32-358.18.1.el6.x86_64
  Runlevel:  N 5 (default: 5)
  SELinux:   enforcing (default: enforcing)
  Sys time:  Thu Sep 12 08:17:11 EDT 2013
  Boot time: Tue Sep 10 07:29:28 EDT 2013 (1378812568)
  Uptime:    2 days, 47 min,  2 users
  LoadAvg:   0.13 (3%), 0.14 (4%), 0.10 (2%)
  Cpu time since boot:
    us 7%, ni 0%, sys 1%, idle 91%, iowait 1%, irq 0%, sftirq 0%, steal 0%
  procs_running (procs_blocked):
    2 (0)
  Kernel taint-check: 0 (kernel untainted)

<snip>
CPU
  4 logical processors (2 CPU cores)
  1 Intel Core i7-2640M CPU @ 2.80GHz (flags: aes,ht,lm,pae,vmx) 
  └─4 threads / 2 cores each
<snip>

So BAM! Right there exactly what we wanted in a nicely-wrapped output.

So we have some formal articles you can refer back to as well:

How to determine number of CPU sockets on a system

and

Difference between physical cpus, cpu cores, and logical cpus

So what do you think? Is this useful stuff? Will this save you any time or even help you start off your own CMDB? We'd love to hear from you!

Cheers,

CRob
Technical Account Manager
Red Hat Inc.

Christopher Robinson's picture

Responses

Hey CRob. Couple points:

  1. The link to KCS "How to determine number of CPU sockets on a system" is wrong.
    See: https://access.redhat.com/site/solutions/61791

  2. Update the version of xsos you have on that lab system. It's insaaaaaaaanely out of date.
    See: Yum repo available for xsos -- a tool for sysadmins

Thanks for the extra eyes Ryan. i've updated both the link AND my workstation for the new xsos!

:-)

Thanks for keeping this post updated, CRob. I'm gonna give it a plug on our social media.

Amusingly, I was having to do this just the other day. Had a dual quad-core server that was showing up as 16 CPUs because of hyperthreading.

Speaking of which: when using performance tools that show CPU data and those tools aren't terribly MP-aware, what's the best way to normalize your data? I mean, a 16vCPU system that's actually only a dual quad-core system isn't technically going to yield 16 CPU's worth of output - at least not under all workloads. What formula would one typically use to normalize raw CPU utilization output to its MP equivalent (i.e., if my CPU non MP-aware tool is showing 735% CPU utilization, how do I put that in terms of my actual CPU carrying-capacity)?

I'm not sure, but it sounds like you're asking for a way to get a usage percentage that caps out at 100%. ...? Assuming I understand you, the answer is going to depend on the tool you're using, right?

For example: with the top command, you can toggle Irix/Solaris mode so that the number of logical processors are taken into account when calculating the cpu usage percentage so that you'll never end up with something like 735%.

Exactly. Specific (ad hoc) use-case was trying to get finer-grained CPU and memory utilization patterns than what sar provides by using the various ps tools.

Thanks for this article and all the comments. Love the /usr/bin/lscpu command when available. I did notice that /usr/bin/lscpu is not available for rhel 5.x. (we still have a small amount of systems on rhel 5.10, eventually all will be on rhel 6.current)

Indeed. All your options are explained in the solution @ Difference between physical cpus, cpu cores, and logical cpus.

Thanks Ryan!

Hi , I am asked to collect the physical CPU, CPU cores and memory on the Server, but i am not sure what is the best metholodgy to check the CPU CORES in Linux VM Server... I dont have either lscpu & xos utilt on it..

dmidecode -t4 | egrep 'Designation|Status'

    Socket Designation: CPU socket #0
    Status: Populated, Enabled
    Socket Designation: CPU socket #1
    Status: Unpopulated
    Socket Designation: CPU socket #2
    Status: Unpopulated
    Socket Designation: CPU socket #3
    Status: Unpopulated
    Socket Designation: CPU socket #4
    Status: Unpopulated
    Socket Designation: CPU socket #5
    Status: Unpopulated
    Socket Designation: CPU socket #6
    Status: Unpopulated
    Socket Designation: CPU socket #7
    Status: Unpopulated

[root@]# dmidecode | grep "Product Name"
Product Name: VMware Virtual Platform
Product Name: 440BX Desktop Reference Platform
[root@]#
[root@]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : AMD Opteron(tm) Processor 6176 SE
stepping : 3
cpu MHz : 2294.319
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good constant_tsc up nonstop_tsc pni cx16 popcnt lahf_lm extapic abm sse4a misalignsse 3dnowprefetch
bogomips : 4588.63
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: [8]
[root@ ~]# uname -a
Linux 2.6.18-348.4.1.el5 #1 SMP Fri Mar 22 05:41:51 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux

Please Suggest the way around to check the CPU CORES and physical cpu on Linux VM!

NOTE:

Only populated and enabled processors in their system sockets are counted as part of requirements and compliance for subscriptions. So for example, if you have a four socket system, but only have two processors installed, configured, and enabled, you only need a subscription for two sockets.

It would be nice now to tie this to how the entitlements work on systems. For example, when you need a (up to 4 sockets) as opposed to (1 socket) for RHEL subscriptions. I've always been confused by this and how/why it's priced that way.

Today I found this helps for physical systems:

yum -y install lshw
lshw -class processor -short 
echo or...
lshw -class processor -short | wc -l
  • That bit above revealed sockets on a physical system. and the below showed a count as well on a physical system...
dmidecode -t4 | egrep CPU 
  • (from rpm -qi lshw) "lshw is a small tool to provide detailed information on the hardware configuration of the machine. It can report exact memory configuration, firmware version, mainboard configuration, CPU version and speed, cache configuration, bus speed, etc. on DMI-capible x86 systems...."

Physical processors and cores per processor could be find in /proc/cpuinfo file:

[root@Desktop]# egrep -i "physical id" /proc/cpuinfo|sort -u
physical id : 0
physical id : 1

[root@Desktop]# egrep -i "core id" /proc/cpuinfo|sort -u
core id     : 0
core id     : 1

or if you dont want to type to much:

[root@server]# egrep -e "core id" -e ^physical /proc/cpuinfo|xargs -l2 echo|sort -u

My System Showing 2 sockets but it attached 4 subscription..How..?

You might want to check the output of 'subscription-manager facts --list' to see how subscription manager sees it

Anyone have thoughts on the best way to verify the number of "enabled" cores on a blade system? I ran into a discrepancy between output from lscpu and dmidecode that has me questioning what is actually enabled. From lscpu I see:

<br />12:40:22 # lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                40
On-line CPU(s) list:   0-31
Off-line CPU(s) list:  32-39
Thread(s) per core:    1
Core(s) per socket:    8
Socket(s):             4
NUMA node(s):          4
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Stepping:              2
CPU MHz:               2597.171
BogoMIPS:              5193.48
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0-4,20-24
NUMA node1 CPU(s):     5-9,25-29
NUMA node2 CPU(s):     10-14,30,31
NUMA node3 CPU(s):     15-19

But dmidecode indicates that all cores for each socket are enabled:

<br />Core Count: 10
        Core Enabled: 10

Curious what thoughts any of you may have on this. Apologies if this isn't the right place to ask this. I can remove if needed.

enabled, you mean to say sockets which are populated, this may help you...

dmidecode --type processor|grep -c "Populated, Enabled" 

Thanks. I am confident in the number of populated sockets. But, wondering the most accurate way to determine how many cores are enabled by querying the OS. These are HP blades and we have run into situations where all the present cores weren't enabled at the chassis management level.

Did you check with "lscpu" command? I could see a lot of options which can show if a particular core is online or not by using lscpu command if this on rhel 6x on-wards..

[root@desktop Desktop]# lscpu --help

Usage:
 lscpu [options]

Options:
 -a, --all               print online and offline CPUs (default for -e)
 -b, --online            print online CPUs only (default for -p)
 -c, --offline           print offline CPUs only
 -e, --extended[=<list>] print out an extended readable format
 -h, --help              print this help
 -p, --parse[=<list>]    print out a parsable format
 -s, --sysroot <dir>     use directory DIR as system root
 -V, --version           print version information and exit
 -x, --hex               print hexadecimal masks rather than lists of CPUs

Available columns:
           CPU  logical CPU number
          CORE  logical core number
        SOCKET  logical socket number
          NODE  logical NUMA node number
          BOOK  logical book number
         CACHE  shows how caches are shared between CPUs
  POLARIZATION  CPU dispatching mode on virtual hardware
       ADDRESS  physical address of a CPU
    CONFIGURED  shows if the hypervisor has allocated the CPU
        ONLINE  shows if Linux currently makes use of the CPU

For more details see lscpu(1).

Like this

[root@desktop Desktop]# lscpu -p --parse=CORE,SOCKET,ONLINE,CONFIGURED
# The following is the parsable format, which can be fed to other
# programs. Each different item in every column has an unique ID
# starting from zero.
# Core,Socket,Online,Configured
0,0,Y,
1,1,Y,
2,2,Y,
3,3,Y,

May be this is what you are looking out here.. ?

So when accounting for purchase, the physical processor is what counts as a socket?

Was this helpful?

We appreciate your feedback. Leave a comment if you would like to provide more detail.
It looks like we have some work to do. Leave a comment to let us know how we could improve.
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.