Re: CPU rounding
- From: Gerry Miller <gerry@xxxxxxxxxxxxxxxxxxx>
- To: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- Date: Fri, 18 Nov 2011 07:22:57 +1000
Niall,
Thanks for that. It is the sort of information I have been looking for. I
will be back on site on Tuesday and will try the prstat command then.
It seems to me that Oracle must have been using different system calls in
10gas CPU is reported in microseconds in that release, or at least it is on
Solaris 9.
Regards
Gerry
Niall Litchfield wrote: Gerry
As promised I did ask around.. I got the following response which looks
pretty accurate to me;
Although Solaris 10 supports CPU timing data in microsecond increments,
Oracle does not appear to use this. Oracle makes calls to the times()
function which is based on the old style sampling performed at each tick,
normally every 10 milliseconds. The behavior Gerry is seeing is expected,
based on the system calls Oracle is making. It is possible to modify the
systemwide clock tick rate to be faster, however this can have some
side-effects. The following blog sheds some light on the considerations:
http://blogs.oracle.com/jtc/entry/overhead_in_increasing_the_solaris[1]
It would be nice if Oracle changed the system calls they use on Solaris, to
retrieve CPU usage. Unfortunately times() is a standard Unix function while
microstate accounting is a Solaris specific implementation. It may not seem
worth the cost for a Solaris specific change like this.
Solaris 10 uses microstate accounting for most statistics reported through
prstat, vmstat and other OS utilities. I recommend using something like "$
prstat -Lma 5" or "$prstat -Lma -p 12345 5" to monitor the OS process of
concern. This will provide very detailed statistics based on CPU state
changes, not sampling. For example:
-bash-3.00$ prstat -Lma -p 24859 5
PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG
PROCESS/LWPID
24859 oracle 8.6 9.3 0.1 0.0 0.0 0.0 78 3.7 7K 1K 21K 0 oracle/1
24859 oracle 0.0 0.0 0.0 0.0 0.0 0.0 100 0.0 0 0 0 0 oracle/2
In this example, the process has two lightweight threads so both are
displayed. The columns show various types of CPU usage and idle times.
These various CPU states are all defined in man pages for prstat.
On Thu, Nov 17, 2011 at 8:22 PM, Gerry Miller <gerry@xxxxxxxxxxxxxxxxxxx[2]>
wrote:
Thanks Joel. Are those databases on the same server, or at least on the same
Solaris version? It could be either the database release or the OS version
that is at fault.
Joel.Patterson@xxxxxxxxxxx[3][1] wrote: column value format
999999999999.999999999999 I get 4 zeroes before the decimal on 11.2.0.1
251290000.000000000000 I get 0 zeroes before decimal on 10.2.0.4
56729894.000000000000 Joel Patterson Database Administrator 904 727-2546[4]
-----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx[5][2]
[mailto:oracle-l-bounce@xxxxxxxxxxxxx[6][3]] On Behalf Of Gerry Miller Sent:
Thursday, November 17, 2011 4:13 AM To: gerry@xxxxxxxxxxxxxxxxxxx[7][4] Cc:
Oracle-L Group Subject: Re: CPU rounding Hi I hate to bang on about this but
I am no nearer to a solution. We have 3 Solaris 10 boxes running 11.2.0.2
Enterprise Edition and the problem exists on all 3 and I would like to ask
anyone with the same configuration out there to run: SELECT value FROM
v$sess_time_model WHERE stat_name = 'DB CPU'; and tell me if the results are
rounded to centiseconds, that is, all end with 4 zeroes. Thanks Gerry Gerry
Miller wrote: Hi, Can any one help me get to the bottom of this? We have two
Solaris servers one hosting Oracle 10.1 and the other 11.2. The CPU stats on
the 11g box are rounded to centiseconds while on 10g they are
inmicroseconds:Example: In 11g: select value from v$sys_time_model where
stat_name = 'DB CPU'; VALUE ----------- 27089090000 In 10g: select value
fromv$sys_time_model where stat_name = 'DB CPU'; VALUE -------------
1373214613234 It is the same in v$sess_time_model and I suspect it is an OS
setting that isat the root of the issue. Regards Gerry Miller --
//www.freelists.org/webpage/oracle-l[5][8] --
//www.freelists.org/webpage/oracle-l[6][9] --
//www.freelists.org/webpage/oracle-l[7][10]
--- Links ---
1 mailto:Joel.Patterson@xxxxxxxxxxx[11]
2 mailto:oracle-l-bounce@xxxxxxxxxxxxx[12]
3 mailto:oracle-l-bounce@xxxxxxxxxxxxx[13]
4 mailto:gerry@xxxxxxxxxxxxxxxxxxx[14]
5 //www.freelists.org/webpage/oracle-l[15]
6 //www.freelists.org/webpage/oracle-l[16]
7 //www.freelists.org/webpage/oracle-l[17]
--
//www.freelists.org/webpage/oracle-l[18]
--
Niall Litchfield
Oracle DBA
http://www.orawin.info[19]
--- Links ---
1 http://blogs.oracle.com/jtc/entry/overhead_in_increasing_the_solaris
2 mailto:gerry@xxxxxxxxxxxxxxxxxxx
3 mailto:Joel.Patterson@xxxxxxxxxxx
4 tel:904%20727-2546
5 mailto:oracle-l-bounce@xxxxxxxxxxxxx
6 mailto:oracle-l-bounce@xxxxxxxxxxxxx
7 mailto:gerry@xxxxxxxxxxxxxxxxxxx
8 //www.freelists.org/webpage/oracle-l%5B5%5D
9 //www.freelists.org/webpage/oracle-l%5B6%5D
10 //www.freelists.org/webpage/oracle-l%5B7%5D
11 mailto:Joel.Patterson@xxxxxxxxxxx
12 mailto:oracle-l-bounce@xxxxxxxxxxxxx
13 mailto:oracle-l-bounce@xxxxxxxxxxxxx
14 mailto:gerry@xxxxxxxxxxxxxxxxxxx
15 //www.freelists.org/webpage/oracle-l
16 //www.freelists.org/webpage/oracle-l
17 //www.freelists.org/webpage/oracle-l
18 //www.freelists.org/webpage/oracle-l
19 http://www.orawin.info
--
//www.freelists.org/webpage/oracle-l
Other related posts:
