Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Processor Count vs Core Count

As Orion tends to have many fields housing the same (or very similar information), I'm working on refining queries to feed our CMDB system. The CMDB folks are looking for both a CPU count and a CPU Core count. What are the best properties to pull those values?

I'm currently keying on Node.CPUCount for the "CPU Core Count", and Node.AssetInventory.ServerInformation.ProcessorCount for "CPU count". Does that seem accurate or am I off-base? Better properties for each?

Find more posts tagged with

Accepted answers

All comments

the_ben_keen

Those are the same things I would key on if I was trying to make this query so I would say you are on the right path.

chucksimalchik

The more I look around, the more I don't know. What of these properties?

AssetInventory.Processor.NumberOfCores

AssetInventory.Processor.NumberOfThreads

the_ben_keen

Can you send me a copy of the SWQL you currently have written up?

the_ben_keen

I just run this general select statement

SELECT TOP 1000 NodeID, 
    SpeedMHz, 
    NumberOfCores,
    NumberOfThreads,
    Name, 
    Stepping,
    Model,
    Caption,
    Manufacturer
FROM Orion.AssetInventory.Processor

And it returned these results:

This is from my home lab where I don't have multi-processor machines but you can for example, my desktop's CPU has 8 cores with 16 threads.

Nodes.CPUCount returns the number of threads a processor has. Which I just confirmed by doing the general select query on Orion.Nodes and comparing the numbers from the first query I did with the results of the query of Orion.Nodes.

chucksimalchik

Certainly a work in progress but building off of this. I've been working on doing similar validation as you have but want to be sure I'm covering all bases.

SELECT
n.Caption
, n.MachineType
, CASE WHEN tostring(n.Category) = '1' THEN 'Network' WHEN tostring(n.Category) = '2' THEN 'Server' ELSE 'Other' END as [Node Category]
, n.IPAddress
, n.Vendor
, n.DNS
, n.CPUCount as [Core Count]
, n.AssetInventory.ServerInformation.ProcessorCount as [Processor Count]
, n.AssetInventory.ServerInformation.OperatingSystem
, n.VirtualMachine.Platform.Name as [Virtualization Platform]
, n.VirtualMachine.UUID
, n.HardwareHealthInfos.ServiceTag
, n.HardwareHealthInfos.Manufacturer
, n.HardwareHealthInfos.Model
, n.CustomProperties.SerialNumber as [CP_SerialNumber]
, n.CustomProperties.SystemRole as [CP_SystemRole]
, n.CustomProperties.ROD_SiteName as [CP_SiteName]
, n.CustomProperties.Server_Description as [CP_ServerDescription]
, n.CustomProperties.Applications as [CP_Applications]
, n.CustomProperties.IncidentSupportGroup
, n.AssetInventory.ServerInformation.Domain
, round((n.TotalMemory/1073741824.0),2) as [GB Memory]

FROM Orion.Nodes n
where n.Category = 2
order by n.caption

chucksimalchik

So what's interesting, taking these fields off of the base Node object (n):

I get these somewhat inconsistent results, particularly when looking at node.cpucount and how it is not populated in some cases:

It seems there are many factors at play here, but when I include the AssetInventory.Processor values, as in the case of the bottom 4 records, they are 4 records from the same machine (1 processor/1 core each) for a total of 4 as shown in the Node.CPUCount. But then the three nodes on top have no processor information even though asset inventory is polled.

Just doesn't seem very straightforward to get a SWQL query to answer these "simple" questions to include in an asset inventory feed. I've been playing with Orion Reports in parallel, but run into similar, though different challenges.