Re: CPU rounding
Date: Fri, 18 Nov 2011 22:15:15 +1000
Message-ID: <4EC64C53.2030103_at_millerandbowman.com>
Hmm, that would suggest that it is an Oracle problem. You may be interested to know that Oracle Support finally tried it on Solarisand got the same outcome. They have now filed bug#13405779.
Gerry
Joel.Patterson_at_crowley.com[1] wrote:
Sorry Gerry, I didn’t see your post for some reason.
Yes, both were on same os version of 5.10
Joel Patterson
Database Administrator
904 727-2546
From: Niall Litchfield [mailto:niall.litchfield_at_gmail.com[2]]
Sent: Thursday, November 17, 2011 4:06 PM
To: gerry_at_millerandbowman.com[3]
Cc: Patterson, Joel; oracle-l_at_freelists.org[4]
Subject: Re: CPU rounding
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[5]
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_at_millerandbowman.com[6]> 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_at_crowley.com[7][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[8]
-----Original Message----- From: oracle-l-bounce_at_freelists.org[9][2]
[mailto:oracle-l-bounce_at_freelists.org[10][3]] On Behalf Of Gerry Miller
Sent:
Thursday, November 17, 2011 4:13 AM To: gerry_at_millerandbowman.com[11][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 --
http://www.freelists.org/webpage/oracle-l[5][12] -- http://www.freelists.org/webpage/oracle-l[6][13] -- http://www.freelists.org/webpage/oracle-l[7][14]
- Links ---
1 mailto:Joel.Patterson_at_crowley.com[15]
2 mailto:oracle-l-bounce_at_freelists.org[16]
3 mailto:oracle-l-bounce_at_freelists.org[17]
4 mailto:gerry_at_millerandbowman.com[18]
5 http://www.freelists.org/webpage/oracle-l[19]
6 http://www.freelists.org/webpage/oracle-l[20]
7 http://www.freelists.org/webpage/oracle-l[21]
--
http://www.freelists.org/webpage/oracle-l[22]
--
Niall Litchfield
Oracle DBA
http://www.orawin.info[23]
- Links ---
1 mailto:Joel.Patterson_at_crowley.com
2 mailto:niall.litchfield_at_gmail.com
3 mailto:gerry_at_millerandbowman.com
4 mailto:oracle-l_at_freelists.org
5 http://blogs.oracle.com/jtc/entry/overhead_in_increasing_the_solaris
6 mailto:gerry_at_millerandbowman.com
7 mailto:Joel.Patterson_at_crowley.com
8 tel:904%20727-2546
9 mailto:oracle-l-bounce_at_freelists.org
10 mailto:oracle-l-bounce_at_freelists.org
11 mailto:gerry_at_millerandbowman.com
12 http://www.freelists.org/webpage/oracle-l%5b5%5d
13 http://www.freelists.org/webpage/oracle-l%5b6%5d
14 http://www.freelists.org/webpage/oracle-l%5b7%5d
15 mailto:Joel.Patterson_at_crowley.com
16 mailto:oracle-l-bounce_at_freelists.org
17 mailto:oracle-l-bounce_at_freelists.org
18 mailto:gerry_at_millerandbowman.com
19 http://www.freelists.org/webpage/oracle-l
20 http://www.freelists.org/webpage/oracle-l
21 http://www.freelists.org/webpage/oracle-l
22 http://www.freelists.org/webpage/oracle-l
23 http://www.orawin.info
--
http://www.freelists.org/webpage/oracle-l