Re: CPU WAIT in OEM (Light green area)

If light green means resmgr:cpu quantum (well, the wait class Scheduler) then resource manager is kicking in because it feels you are at your CPU capacity or you have a max utilisation resource directive or perhaps you are reaching the cpu limit of standard edition.

Is resource manage enabled? Have you licensed the diagnostic pack so you can see what has been waiting on this event?

It is a problem if your critical processes are hitting it. If set up properly, this should be saving your critical processes from slowing down when you have non-critical processes trying to use your CPU.

Hope that helps get you started,
Andy

On Mon, 18 Nov 2019 at 01:35, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

> Hi Jack!
>
> Vmstat is the wrong tool to measure CPU. You should use sar or mpstat. I
> prefer "mpstat" because it's more modern and provides more data:
>
> root_at_umajor:/home/mgogala# mpstat 3 3
> Linux 5.3.0-24-generic (umajor) 11/17/2019 _x86_64_ (16 CPU)
>
> 08:13:40 PM CPU %usr %nice %sys %iowait %irq %soft %steal
> %guest %gnice %idle
> 08:13:43 PM all 0.06 0.00 0.04 0.00 0.00 0.00
> 0.00 0.00 0.00 99.90
> 08:13:46 PM all 0.15 0.00 0.25 0.00 0.00 0.00
> 0.00 0.00 0.00 99.60
> 08:13:49 PM all 0.04 0.00 0.06 0.00 0.00 0.00
> 0.00 0.00 0.00 99.90
> Average: all 0.08 0.00 0.12 0.00 0.00 0.00
> 0.00 0.00 0.00 99.80
>
> However, "sar" is also good:
>
> root_at_umajor:/home/mgogala# sar -u 3 3
> Linux 5.3.0-24-generic (umajor) 11/17/2019 _x86_64_ (16 CPU)
>
> 08:16:15 PM CPU %user %nice %system %iowait %steal
> %idle
> 08:16:18 PM all 0.10 0.00 0.08 0.00 0.00
> 99.81
> 08:16:21 PM all 0.33 0.00 0.17 0.00 0.00
> 99.50
> 08:16:24 PM all 0.06 0.00 0.02 0.00 0.00
> 99.92
> Average: all 0.17 0.00 0.09 0.00 0.00
> 99.74
>
> Major advantage of sar over mpstat is the fact that you can go up to a
> month back in time and investigate. If you're using Red Hat or a
> derivative, he files are in /var/log/sa:
>
> [root_at_ora122 sa]# sar -u -f sa24
> Linux 4.14.35-1902.4.8.el7uek.x86_64 (ora122) 08/24/2019
> _x86_64_ (3 CPU)
>
> 10:53:20 AM LINUX RESTART
>
> 11:00:01 AM CPU %user %nice %system %iowait %steal
> %idle
> 11:10:01 AM all 3.26 0.00 0.41 0.65 0.00
> 95.69
> 11:20:01 AM all 0.85 0.00 0.26 0.17 0.00
> 98.72
> 11:30:01 AM all 0.27 0.22 1.17 0.16 0.00
> 98.19
> 11:40:01 AM all 0.21 0.00 0.20 0.08 0.00
> 99.51
> 11:50:01 AM all 0.80 0.00 0.22 0.11 0.00
> 98.87
> Average: all 1.08 0.04 0.45 0.23 0.00
> 98.20
>
> 12:34:10 PM LINUX RESTART
>
> 12:40:01 PM CPU %user %nice %system %iowait %steal
> %idle
> 12:50:01 PM all 0.24 0.00 0.16 0.09 0.00
> 99.51
> 01:00:01 PM all 2.31 0.00 0.34 0.22 0.00
> 97.12
> Average: all 1.27 0.00 0.25 0.15 0.00
> 98.32
> [root_at_ora122 sa]#
>
> Snapshots are taken 10 minutes apart and usually go up to a month back. I
> am using virtual machines which can be inactive for several days. Other
> than that, you can see CPU Wait event if you are using
> DBMS_RESOURCE_MANAGER. However, if uptime and other tools, show that the
> CPU is not much used, then don't pay any attention to that event.
>
> Regards
>
>
> On 11/17/19 7:53 PM, Jack van Zanen wrote:
>
> Hi All
>
>
> I am seeing on occasion that CPU WAIT in OEM graph gets very prominent
> According to "
> https://blog.orapub.com/20150210/what-is-light-green-oracle-database-cpu-wait-time.html
> "
> The CPU WAIT is when Oracle is waiting to get on CPU (in the queue)
>
> I would however expect to see CPU pressure when this happens
>
> however on OS CPU have lots of IDLE time
>
> [oracle_at_cltsadm01vm01 AWR]$ vmstat 10 10
> procs -----------memory---------- ---swap-- -----io---- --system--
> -----cpu-----
> r b swpd free buff cache si so bi bo in cs us sy id
> wa st
> 13 0 0 91456296 1246408 72531584 0 0 8 32 0 0 22
> 4 74 0 0
> 9 0 0 91441104 1246408 72532288 0 0 0 188 50024 41230
> 28 3 69 0 0
> 13 0 0 91481680 1246408 72533216 0 0 1 266 48898 41615
> 28 3 69 0 0
> 9 0 0 91487496 1246408 72536520 0 0 0 242 60376 46185
> 26 3 71 0 0
> 10 0 0 91501456 1246408 72537696 0 0 1 196 45629 37927
> 24 5 71 0 0
> 12 0 0 91464880 1246412 72541536 0 0 0 252 46247 39331
> 29 4 67 0 0
>
>
>
>
> Jack van Zanen
>
>
> -------------------------
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient. If you are not the intended recipient,
> please be aware that any disclosure, copying, distribution or use of this
> e-mail or any attachment is prohibited. If you have received this e-mail in
> error, please contact the sender and delete all copies.
> Thank you for your cooperation
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
>
>

--
http://www.freelists.org/webpage/oracle-l