Solaris Operating System

83 cputrack Command

• Password Protect Your Usb Drive
• How do I free up disk space?

While the cpustat command monitors activity for the entire system, the cputrack command allows the same counters to be measured for a single process. This can be useful for focusing on particular applications and determining whether only one process is the cause of performance issues.

The event specification for cputrack is the same as cpustat, except that instead of an interval and a count, cputrack takes either a command or -p pid.

# cputrack

Usage:

cputrack [-T secs] [-N count] [-Defhnv] [-o file] -c events [command [args] | -p pid]

-T	secs	seconds between samples, default 1
-N	count	number of samples, default unlimited
-D		enable debug mode
-e		follow exec(2), and execve(2)
-f		follow fork(2), fork1(2), and vfork(2)
-h		print extended usage information
-n		suppress titles
-t		include virtualized %tick register
-v		verbose mode
-o	file	write cpu statistics to this file
-c	events	specify processor events to be monitored
-p	pid	pid of existing process to capture

Use cpustat(iM) to monitor system-wide statistics.

Use cpustat(iM) to monitor system-wide statistics.

The usage message for cputrack ends with a reminder to use cpustat for systemwide statistics.

The following example demonstrates cputrack monitoring the instructions and cycles for a sleep command.

# cputrack -c pic0=Instr_cnt,pic1=Cycle_cnt sleep 5

time	lwp	event	pic0	pic1
1.024	1	tick	188134	629987
2.023	1	tick	0	0
3.023	1	tick	0	0
4.023	1	tick	0	0
5.023	1	tick	0	0
5.034	1	exit	196623	682808

In the first second, the sleep command initializes and executes 188, 134 instructions. Then the sleep command sleeps, reporting zero counts in the output; this shows that cputrack is monitoring our sleep command only and is not reporting on other system activity. The sleep command wakes after five seconds and executes the final instructions, finishing with the total on exit of 196, 623 instructions.

As another example, we use cputrack to monitor the D-cache activity of PID 19849, which has multiple threads. The number of samples is limited to 20 (-n).

$ cputrack -N 20 -c pic0=DC_access ,pic1=DC_miss -p 19849

1.	007	1	tick	34543793	824363
1.	007	2	tick	0	0
1.	007	3	tick	1001797338	5153245
1.	015	4	tick	976864106	5536858
1.	007	5	tick	1002880440	5217810
1.	017	6	tick	948543113	3731144
2.	007	1	tick	15425817	745468
2.	007	2	tick	0	0
2.	014	3	tick	1002035102	5110169
2.	017	4	tick	976879154	5542155
2.	030	5	tick	1018802136	5283137
2.	033	6	tick	1013933228	4072636

This CPU type provides D-cache misses for pic1, a useful statistic inasmuch as cache misses incur a certain time cost. Here, lwp 2 appears to be idle, while lwps 3, 4, 5, and 6 are causing many D-cache events. With a little awk, we could add another column for D-cache hit ratio.

For additional information on cputrack, see cputrack(1).

4 PREV

NEXT

PREV NEXT

8.4. busstat Command

The busstat command monitors bus statistics for systems that contain instrumented buses. Such buses contain Performance Instrumentation Counters (PICs), which in some ways are similar to the CPU PICs.

8.4.1. Listing Supported Buses busstat -l lists instrumented buses that busstat can monitor. # busstat -l busstat: No devices available in system.

If you see the "No devices available" message, then you won't get any further. Find another system (usually a larger system) that responds by listing instance names. The following is from a Sun Enterprise E4500.

Busstat Device (s) :

sbus1 ac0 ac1 ac2 ac3 ac4 sbus0 sbus2 sbus3 sbus4

The output of busstat -l has now listed six devices that provide PICs for us to use. sbus is for SBus, the interconnect bus for devices including peripherals; ac is for Address Controller.

8.4.2. Listing Bus Events

The -e switch for busstat lists events that a bus device can monitor. Here we list events for ac0.

# busstat -e ac0 pic0

mem_bank0_rds mem_bank0_wrs mem_bank0_stall mem_bank1_rds mem_bank1_wrs mem_bank1_stall clock_cycles pic1

mem_bank0_rds mem_bank0_wrs mem_bank0_stall mem_bank1_rds mem_bank1_wrs mem_bank1_stall clock_cycles

The list of events for each PIC is very long; we truncated it so that this example doesn't fill an entire page.

It can help to use the pr command to rework the output into columns. The following example does this for the sbus0.

pic0

pic1

dvma_stream_wr dvma_const_rd dvma_const_wr dvma_tlb_misses dvma_stream_buf_mis dvma_cycles dvma_bytes_xfr interrupts upa_inter_nack pio_reads pio_writes sbus_reruns pio_cycles #

eam_rd dvma_stream_wr dvma_const_rd dvma_const_wr dvma_tlb_misses dvma_stream_buf_mis dvma_cycles dvma_bytes_xfr interrupts upa_inter_nack pio_reads pio_writes sbus_reruns pio_cycles

The first column lists events for pico; the second are events for pici.

Unlike cpustat, busstat does not finish by listing a reference manual for these events. There is currently little public documentation for bus events^4-; most Internet searches match only the man page for busstat and the event names in the OpenSolaris source. Fortunately, many of the event names are self-evident (for example, mem_banko_rds is probably memory bank 0 reads), and some of the terms are similar to those used for CPU PICs, as documented in the CPU manuals.

[4] Probably because no one has asked! busstat is not in common use by customers; the main users have been engineers within Sun.

8.4.3. Monitoring Bus Events

Monitoring bus events is similar to monitoring CPU events, except that we must specify which bus instance or instances to examine.

The following example examines aci for memory bank stalls, printing a column for each memory bank. We specified an interval of 1 second and a count of 5.

#	busstat	-w ac1,pic0	=mem bankO	stall ,pic1:	=mem bankl stall 1 5
time dev		eventO		pic0	event1	pic1
1	ac1	mem bankO	stall	2653	mem bankl stall	O
2	ac1	mem bankO	stall	2O39	mem bankl stall	O
3	ac1	mem bankO	stall	3614	mem bankl stall	O
4	ac1	mem bankO	stall	3213	mem bankl stall	O
5	ac1	mem bankO	stall	2 3 8O	mem bankl stall	O

The second bank is empty, so pici measured no events for it. Memory stall events are interestingthey signify latency suffered when a memory bank is already busy with a previous request.

There are some differences between busstat and cpustat: There is no total line with busstat, and intervals less than one second are not accepted. busstat uses a -w option to indicate that devices are written to, thereby configuring them so that their PICs will monitor the specified events, whereas cpustat itself writes to each CPU's PCR.

By specifying ac instead of aci, we now monitor these events across all address controllers.

#	busstat	-w ac,pic0=mem bankO	stall,pic1=mem bankl stall 1 5
time dev		eventO	picO	eventl	picl
l	acO	mem bankO stall	2 6 4l	mem bankl stall	O
l	acl	mem bankO stall	2766	mem bankl stall	O
l	ac2	mem bankO stall	O	mem bankl stall	O
l	ac3	mem bankO stall	O	mem bankl stall	O
l	ac4	mem bankO stall	O	mem bankl stall	O
2	acO	mem bankO stall	2374	mem bankl stall	O

2 ac2 mem_bank0_stall 0

2 ac3 mem_bank0_stall 0

2 ac4 mem_bank0_stall 0

3 ac0 mem bank0 stall 2133

mem_bank1_stall mem_bank1_stall mem_bank1_stall mem_bank1_stall mem bank1 stall

We would study the dev column to see which device the line of statistics belongs to.

busstat also provides a -r option, to read PICs without changing the configured events. This means that we monitor whatever was previously set by -w. Here's an example of using -r after the previous -w example.

# busstat -r ac0 1 5

time	dev	event0		pic0	event1	pic1
1	ac0	mem bankO	stall	2039	mem bankl stall	0
2	ac0	mem bank0	stall	1822	mem bank1 stall	0
3	ac0	mem bank0	stall	1868	mem bank1 stall	0
4	ac0	mem bank0	stall	2109	mem bank1 stall	0
5	ac0	mem bank0	stall	1779	mem bank1 stall	0

0 0