Mutex 争用解析

导读
上一篇文章介绍了latch争用的相关内容，本文继续介绍与latch相关的mutex争用的相关内容。

1、Mutex故障排除

查看相关视图

v$session

V$SESSION_WAIT  

P1,P2,P3值表示library cache 对象在争用状态下的哈希值，即持有mutex的会话。

V$event_name和V$session_wait的 "text"列记录了P1, P2, P3

从上面的视图中，可以查看到相关的mutex等待事件：

• cursor: mutex S
• cursor: mutex X
• library cache: mutex S
• library cache: mutex X

V$MUTEX_SLEEP  ：显示等待时间，以及每个mutex类型和位置组合的sleep次数。

V$MUTEX_SLEEP_HISTORY  ：显示mutex sleep的最后单个事件，基于一个最详细的循环缓冲区 	

2、Mutex等待及含义

2.1、cursor: mutex S

我们尝试在共享模式下获得父游标或V$SQLSTAT桶上的互斥锁。

互斥锁处于“变化中”(有人正在以共享模式获取它)，所以我们必须等到持有者完成它的共享获取。

如何使用:

•检查父游标，查询V$SQLSTATS桶。

2.2、cursor: mutex X

我们尝试在独占模式下获得父游标或V$SQLSTAT桶上的mutex，有人已经在不兼容模式下持有该mutex，或者有人已经在X模式下持有mutex，或者在S模式下可能有多个持有者。

如何使用：

在父游标下加载新的子游标，修改V$SQLSTATS桶，更新绑定捕获数据。

2.3、cursor: pin S

我们尝试将游标固定在共享模式(例如用于执行)。

子游标固定的mutex是“在变化中”，有人已经在固定同一个游标了。

我们必须等到其他会话完成他们的pin请求。

2.4、cursor: pin X

我们尝试在独占模式pin一个游标，但有人已经在不兼容模式将其pin。

或者一个session已经在X模式pin该游标，或者多个session在S模式pin该游标。

2.5、cursor: pin S wait on X

我们尝试在共享模式下pin一个游标，但是有人已经在X模式下pin该游标。其他会话当前正在加载该子游标(解析)。

在11g中，大多数库缓存latch都直接被库缓存哈希桶上的mutex所取代。

每个哈希桶都由一个单独的mutex保护

2.6、library cache: mutex S

试图在S模式下获得库缓存哈希桶上的mutex

mutex已经保持在不兼容模式或处于“in flux ”

2.7、library cache: mutex X

试图在X模式下获得库缓存哈希桶上的mutex

mutex已经处于不相容的模式或处于“in flux ”

3、查看mutex相关的等待事件解释

SQL> select NAME,PARAMETER1,PARAMETER2,PARAMETER3,WAIT_CLASS from v$event_name where PARAMETER1='idn';
NAME                           PARAMETER1 PARAMETER2 PARAMETER3           WAIT_CLASS
------------------------------ ---------- ---------- -------------------- --------------------
cursor: mutex X                idn        value      where|sleeps         Concurrency
cursor: mutex S                idn        value      where|sleeps         Concurrency
cursor: pin S wait on X        idn        value      where|sleeps         Concurrency
library cache: mutex X         idn        value      where                Concurrency
library cache: mutex S         idn        value      where                Concurrency
cursor: pin X                  idn        value      where|sleeps         Other
cursor: pin S                  idn        value      where|sleeps         Other
7 rows selected
SQL> 

与任何等待事件一样，参数(P1、P2、P3)提供了关于等待的额外细节和上下文信息

Parameter1 (idn)可用于查找与互斥锁相关的游标

Parameter2 (value)可用于查找以独占模式持有mutex的会话

对于所有共享模式持有者，都需要系统状态转储

3.1、PARAMETER1 - idn

cursor:* 等待事件

idn = 受保护的库缓存对象的哈希值  

library cache: mutex* 等待事件

(1)库缓存哈希桶号 (if idn <= 131072)
(2) idn = 受保护的库缓存对象的哈希值 (if idn >131072)  

通过hash_value 查找SQL

SELECT sql_text FROM v$sql WHERE hash_value = &idn;

通过库缓存桶查找SQL(idn <= 131072):

SELECT sql_text FROM v$sql WHERE MOD(hash_value, 131072) = &idn;

从AWR中通过SQL_ID查找SQL (hash_value is the lower half of SQLID):

SELECT sql_text FROM dba_hist_sqlstat
WHERE tpt.sqlid_to_sqlhash( sql_id ) = &idn;  

3.2、PARAMETER2 - value

 low bytes of word (2 or 4 bytes) - number of mutex shared references
 high bytes of word (2 or 4 bytes) - SID of exclusive holder  

SQL> select session_id, event, blocking_session,
2 to_char(p2, '0XXXXXXX') value_hex
3 from v$active_session_history
4 where event like 'library cache: mutex%';
SESSION_ID EVENT BLOCKING_SESSION VALUE_HEX
---------- --------------------------- ---------------- ---------
157 library cache: mutex X 00830000

3.3、PARAMETER 3 - where

 where = maps to x$mutex_sleep.location_id

有助于理解从哪个内核函数中执行MUTEX 的get操作 ，用于高级诊断。

4、mutex的根因

在正常情况下，mutex等待意味着高并发性。

当环境强制非顺序执行时，更有可能发生mutex等待的问题。

这是CPU超额分配的问题，迫使进程随机休眠。

一个简单的公式来确定您的机器是否被超额分配CPU:

(total) AAS > # CPU cores

所以100%的CPU使用率不是CPU的最佳使用。

在我遇到的大多数latch和mutex问题中，最终证明是CPU超额分配放大了互斥锁等待