Go to main content

Using Oracle® Solaris 11.4 StatsStore and System Web Interface

Exit Print View

Updated: February 2019
 
 

Representing Topology

Topology shows the structure of the system by expressing relationships between system resources. The statistics store represents system topology by combining multiple canonical resource names, where a canonical resource name is a class, res pair. The last canonical name in the SSID is the name of the resource whose topology is described by the SSID. A //:class after a //:res is a topological link to related resources. If you are not familiar with the structure of the system, these SSIDs can help you explore the topology.

Topology mapping can also provide a more user-friendly SSID by omitting implementation details. For example, the kstat or dtrace provider name could be omitted. The following two SSIDs represent the same statistic:

//:class.kstat//:res.disk/sd/sd0/0//:stat.nread
//:class.io//:res.name/sd0//:stat.nread

Often a topology is valid only for a specific time period because events such as failures and hotplug operations change the configuration of a system. To explore past topology, specify the time range with the sstore export command as shown in Using Command Line Interfaces.

The following SSIDs show that this system has only one processor set and one chip but has four cores and four CPUs. All pset and chip resource values are id/0, while core and cpu resources values are id/0, id/1, id/2, and id/3.

$ sstore list //:class.cpu//:res.*//:class.*//:res.*
IDENTIFIER
//:class.cpu//:res.id/0//:class.chip//:res.id/0
//:class.cpu//:res.id/0//:class.core//:res.id/0
//:class.cpu//:res.id/0//:class.pset//:res.id/0
//:class.cpu//:res.id/1//:class.chip//:res.id/0
//:class.cpu//:res.id/1//:class.core//:res.id/1
//:class.cpu//:res.id/1//:class.pset//:res.id/0
//:class.cpu//:res.id/2//:class.chip//:res.id/0
//:class.cpu//:res.id/2//:class.core//:res.id/2
//:class.cpu//:res.id/2//:class.pset//:res.id/0
//:class.cpu//:res.id/3//:class.chip//:res.id/0
//:class.cpu//:res.id/3//:class.core//:res.id/3
//:class.cpu//:res.id/3//:class.pset//:res.id/0

The following command shows an alternative way to explore relationships among cores, chips, and CPUs. The previous example shows that CPUs have cores, chips, and processor sets. The following example shows that cores have chips and CPUs.

$ sstore list //:class.core//:res.id/*//:*//:*
IDENTIFIER
//:class.core//:res.id/0//:class.chip//:res.id/0
//:class.core//:res.id/0//:class.cpu//:res.id/0
//:class.core//:res.id/1//:class.chip//:res.id/0
//:class.core//:res.id/1//:class.cpu//:res.id/1
//:class.core//:res.id/2//:class.chip//:res.id/0
//:class.core//:res.id/2//:class.cpu//:res.id/2
//:class.core//:res.id/3//:class.chip//:res.id/0
//:class.core//:res.id/3//:class.cpu//:res.id/3
//:class.core//:res.id/2//:class.cpu//:res.id/2

The following command confirms that these SSIDs are topology links:

$ sstore info //:class.core//:res.id/2//:class.cpu//:res.id/2
 Identifier: //:class.core//:res.id/2//:class.cpu//:res.id/2
  stability: stable
description: topology link
$ sstore info //:class.cpu//:res.id/3//:class.core//:res.id/3
 Identifier: //:class.cpu//:res.id/3//:class.core//:res.id/3
  stability: stable
description: topology link

You can query statistics and events by specifying only the last canonical resource name in the SSID, as shown by the following comparison:

$ sstore list //:class.core//:res.id/2//:class.cpu//:res.id/2//:*
IDENTIFIER
//:class.core//:res.id/2//:class.cpu//:res.id/2//:class.chip
//:class.core//:res.id/2//:class.cpu//:res.id/2//:class.core
//:class.core//:res.id/2//:class.cpu//:res.id/2//:class.pset
//:class.core//:res.id/2//:class.cpu//:res.id/2//:event.adm-action
//:class.core//:res.id/2//:class.cpu//:res.id/2//:event.alert
//:class.core//:res.id/2//:class.cpu//:res.id/2//:event.fault
//:class.core//:res.id/2//:class.cpu//:res.id/2//:stat.usage
//:class.core//:res.id/2//:class.cpu//:res.id/2//:stat.interrupt-count
//:class.core//:res.id/2//:class.cpu//:res.id/2//:stat.interrupt-time
//:class.core//:res.id/2//:class.cpu//:res.id/2//:stat.xcalls
$ sstore list //:class.cpu//:res.id/2//:*
IDENTIFIER
//:class.cpu//:res.id/2//:class.chip
//:class.cpu//:res.id/2//:class.core
//:class.cpu//:res.id/2//:class.pset
//:class.cpu//:res.id/2//:event.adm-action
//:class.cpu//:res.id/2//:event.alert
//:class.cpu//:res.id/2//:event.fault
//:class.cpu//:res.id/2//:stat.usage
//:class.cpu//:res.id/2//:stat.interrupt-count
//:class.cpu//:res.id/2//:stat.interrupt-time
//:class.cpu//:res.id/2//:stat.xcalls