Another Cooltst interpretation

I need some help since I think the FP usage I am seeing is artificial.

I am running cooltst on a v880 server running Solaris 8 with 4 900mh IIIi processors. I am seeing 1.2 - 1.8 FP usage over the course of the day (we ran cooltst hourly).

I saw another discussion where it mentioned some of the older platforms used FP statements to implement memcpy and this has been changed on S10 for the t2000 to eliminate the FP usage. This is an Oracle database server (Oracle 9.2 ?not sure what patchset or bit size). I just want to confirm that this is normal behavior for Oracle and I shouldn抰 worry about it. Supposedly there are no float data types in the database design.

Here is the cooltst output from a sample session:

cooltst.ksh v2.3.2

System configs

Host Name:bmgodb1

Chip Arch:US-III+

OS:SunOS 5.8, 64-bit

[Virtual]Processors:4

processor0on-line900 MHz

processor1on-line900 MHz

processor2on-line900 MHz

processor3on-line900 MHz

=> Running cpustat... (08/22/06 01:00:02)

=> Runtime (cpustat) ended... (08/22/06 01:02:18)

=> Running procls.sh... (08/22/06 01:02:18)

=> Completed data collection... (08/22/06 01:02:18)

=> Analysis of collected data... (08/22/06 01:02:18)

FP: YELLOW (FP Component may be too high (1.44%). Further checking required.)

PROCESSES FOR ANALYSIS:

Process Summary:

320 Active Processes, 3261 LWPs

PID NLWP CMD

1299311 ora_j000_BMPR1 (22.8%)

666913 ora_s000_BMPR3 (19.2%)

153064 /usr/sbin/save (18.4%)

152944 /usr/sbin/save (17.2%)

153084 /usr/sbin/save (10.4%)

667911 ora_s005_BMPR3 (6.0%)

669311 ora_s012_BMPR3 (5.2%)

674911 ora_arc0_BMPR3 (5.2%)

665913 ora_lgwr_BMPR3 (4.8%)

668911 ora_s010_BMPR3 (4.8%)

670311 ora_s017_BMPR3 (4.4%)

31 fsflush (3.2%)

1223111 ora_s000_BMPR1 (3.2%)

2281711 ora_s015_BMPR3 (3.2%)

33714 /usr/lib/picl/picld (2.8%)

2719311 ora_s020_BMPR3 (2.8%)

6657 258 ora_dbw0_BMPR3 (2.4%)

671111 ora_s021_BMPR3 (2.4%)

2328211 ora_s028_BMPR3 (2.4%)

670711 ora_s019_BMPR3 (2.0%)

67371 ora_d004_BMPR3 (2.0%)

927211 ora_s001_BMPR3 (2.0%)

153014 /usr/sbin/save (2.0%)

2328011 ora_s023_BMPR3 (2.0%)

572311 ora_s027_BMPR3 (1.6%)

625711 ora_s011_BMPR3 (1.6%)

?br>

and here is the output from cpustat_summary:

FA_pipe_completion

CPU ID2 3 0 1Avg StdDev

user 1002897.1151046441.5381069946.8851052122.5001042852.01028456.707

total 2096924.8082307368.6542076715.6152024549.5002126389.644124446.110

sys1094027.6921260927.1151006768.731972427.0001083537.635128861.821

FM_pipe_completion

CPU ID2 3 0 1Avg StdDev

user11707.15413081.26912376.19211543.46212177.019702.260

total22777.07724203.61522629.07721279.61522722.3461195.453

sys 11069.92311122.34610252.8859736.15410545.327670.432

Instr_cnt

CPU ID2 3 0 1Avg StdDev

user108849806.288 112104061.769 105507879.192 101715728.173 107044368.8564457776.303

total149247289.712 157283062.500 146281019.038 145550609.692 149590495.2365371737.430

sys 40397483.42345179000.73140773139.84643834881.51942546126.3802334742.310

# End of cpustat_summary

Thanks!

Andy

[3369 byte] By [andymac] at [2007-11-26 9:38:36]
# 1

The count could be inflated by floating point registers being used to move data. You'll notice that the system ratio is surprisingly high. This is probably due to block moves of data which is counted by the event counters. On the user side, the average ratio is 0.986% and many of these could also be block moves. Unfortunately, disambiguating block moves of data from floating point instructions is not possible. Based on knowledge of the application environment, which you have described, one can infer that the actual floating is less than counted. Our experience with Oracle on T1000/T2000 servers has been positive. You will probably have a good experience.

rml at 2007-7-7 0:33:41 > top of Java-index,Open Source Technologies,OpenSPARC...