cursor.pin S 故障与HIGH CPU useage 故障的故障解决

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE 案例是这样的： CPU 在某些情况下会 JUMP 到 100%

AWR 报告中有大量的CURSOR.PIN S 占了5-10%

V$EVENT_HISTOGRAM VIEW 西安市 CURSOR.PIN S 大量情况超过1秒

有些甚至超过了30秒。

 

 

首先高CPU有可能是 LOGON LOGOFF storm 引发的。

每二十分钟检查一次AWR 发现 logons cumulative 并没有明显增长。

 

log file sync 从平均-1-2ms 增长到了20-60 ms

但是log file parallel write 却没有增长的很快 这意味着 sync的可能在等待一些其他的东西

看起来很像 CPU scheduling latency（当CPU 繁忙时等待CPU unquene）

 

一般当遇到像CURSOR.PIN S 这样的问题时

可以考虑检查 V$MUTEX_SLEEP_HISTORY

但是这次看起来并没有发现有很特别的等待对象  所有的等待都很平均的等待不同的CURSOR（所以这种情况提醒我 这并非是某个单独cursor 的问题 比如说一个BUG或者频繁使用的CURSOR产生的问题）（这个VIEW 不是在产生问题的时候查询的  所以也有可能没指出问题所在  这个VIEW 是一个环形buffer 只记录了最后的几百个游标等待情况）

 

所以 情况就是 CPU 资源紧张 同时还有很长的CURSOR,PIN  S等待

无论何时如果你看到 CPU 100%同时有 LATCH 竞争 那么首先需要解决CPU 100%的问题 因为latch也是因为ＣＰＵ争用而产生的

 

如果很不幸　持有ｌａｔｃｈ的进程正在做某些事情　那么他将会持有到他释放结束（假如他无法得到ＣＰＵ的话……）

当拿不到latch的人就会进入自旋 企图等一段时间以后可以获得这个latch。

 

但是这个case 不一样 因为连holder 也无法得到CPU 来do something.

 

在10.2之后 latch和mutexes 有个巨大的不同

Latch如果拿不到CPU的话 会自旋 然后睡一会 起来再度尝试

而mutex 则会yield() CPU 并且在此尝试获得CPU ，所以10.2中的MUTEX是一个恐怖的存在 他们将会尝试以最大的能量去获取某个不属于他们的CPU 这样也会消耗大量的CPU。

 

但是这又如何？一旦mutex holder抢占了CPU 那么他应该立刻可以工作并且很快完成。

没错 前提需要他们有相同的优先级才行。

 

在UNIX系统中 当一个进程消耗了大量CPU 的时候 OS就会降低他的优先级来让其他不是很饥饿的进程来享受CPU 这样来保证每个进程都可以公平的使用CPU。

 这样当一个MUTEX holder 拿到了CPU时 他的优先级却被降低了 于是他又被off cpu…..这样他的工作就完不成了。

 

当得知了这个原因的时候我们检查了所有的ORACLE进程 发现一部分进程的优先级极低，

Bug 6904068 High CPU usage when there are “cursor: pin S” waits

Bug 7441165 – Prevent preemption while holding a mutex

为了解决这个问题 我们需要enable HPUX_SCHED_NOAGE来阻止UNIX 降低进程优先级，并且设置_first_spare_parameter=10 来让mutex sleep 10厘秒(这个时间蛮长的了……)

 

CPU runqueue 是指CPU 工作队列

The run queue may contain priority values for each process, which will be used by the scheduler to determine which process to run next.

在linux中 每一个CPU 都有一个runqueue 每一个runqueue可能包含两个array (active)(expired)

当一个进程通过scheduler分配进CPU时 就会被分配一个quantum（类似于工作时间啦） 当这个时间结束的时候就会被T出来放到expired 队列中。 然后scheduler再从active 的队列中挑一个扔进去。

当active中没有等待的process时  就会将expired 队列中的与active中的进行swap。

 

当一个进程需要sleep的时候就会被移出runqueue。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/21818314/viewspace-687641/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/21818314/viewspace-687641/