library cache: mutex X 等待事件分析

应用性能压测并发上不去，数据库中大量等待library cache： mutex X等待事件。

什么是 'library cache： mutex X' 等待？

mutex 功能是一种控制对 in memory 结构的访问的机制。它用于许多领域，包括库缓存。

库缓存是一个内存区域，其中包含执行 SQL 所需的已解析游标结构。

'library cache： mutex X' 的等待类似于早期版本中的库缓存等待。'library cache： mutex X' 可能是由许多问题引起的（包括应用程序问题、缺乏共享导致高版本数等），但本质上是某些东西持有互斥锁 “太久” 以至于其他会话必须等待资源。如果保护库缓存结构的 latches/mutexs 存在争用，这意味着解析系统存在压力。解析 SQL 需要更长的时间，因为它无法获取所需的资源。这会延迟其他操作，并且通常会减慢系统速度。

是什么导致 'library cache： mutex X' 等待？

* 频繁的硬解析 - 如果硬解析的频率非常高，则此引脚上可能会发生争用。

* 高版本计数 - 当版本计数变得过多时，需要检查一长串版本，这可能会导致对此事件的争用

* Invalidations （失效） - 失效是衡量缓存的游标因不再有效而从缓存中删除的次数的指标。游标无效，因为某些内容已更改，因此内存中的游标副本不再有效。例如，重新收集有关对象的统计信息或修改表定义足以使基于该对象的查询的游标失效。当游标失效时，任何想要使用该游标的会话都需要等待加载有效版本。如果存在过多或不必要的失效，则可以看到对 'library cache： mutex X' 的大量等待。

* Reloads - Reload 是以前存在于缓存中的游标被搜索、发现不存在（因为它已经过期等）然后必须重新编译并重新加载到库缓存中的次数。高重新加载是一件坏事，因为它们表明您正在执行的工作，如果缓存设置得当，则不必首先删除光标。如果正在重新加载游标，则会话无法抓取它以进行工作，这可能导致等待 'library cache： mutex X'。

* 已知 Bug

awr报告中library cache: mutex X等待事件占据主要DB time耗时

高并发的硬解析SQL

从时间模型看，解析时间占比总DB time的92%，硬解析占比89%，说明耗时主要来源于硬解析。

每秒平均211个硬解析SQL

高并发的硬解析SQL（且SQL文本较长）导致严重的library cache: mutex X竞争等待。

最终，v$sql中找到硬解析SQL，应用改写将拼接SQL改为绑定变量SQL，library cache: mutex X等待事件消失，SQL压测并发增加20倍。

参考文档：Troubleshooting 'library cache: mutex X' Waits. (Doc ID 1357946.1)

原文地址：https://blog.csdn.net/Story_begins/article/details/142887508

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！