从有限的信息中无法确定页面和行锁哈希表上的争用是实际问题还是其他问题的征兆，例如，进程遇到某种其他争执，这反过来又导致它们花费更长的时间 比正常情况更容易处理锁？

虽然20％听起来很高，但这是一个相对数字，因此某些情况会有所帮助，例如，在30分钟的时间段内，100个自旋锁请求中的20％可能不算什么大问题 在1分钟的时间内有1000万个自旋锁请求。

--------

假设您已经排除了有关CPU使用率高的"正常"解释（例如，逻辑IO计数高，需要编译的查询量大，配置已知/错误），那么我想得到一个更好的解释 有关该时段内所有自旋锁活动的图片...尽管您可以浏览 sp_sysmon 结果（以及潜在的自旋锁数据），但查询 master可能会容易一些。 .monSpinlockActivity （MDA）表。

注意：您还可以向技术支持索取名为 sp_spinmon 的自定义proc的副本以及使用说明，该自定义proc还可以提供有关自旋锁问题的详细信息。

由于 monSpinlockActivity 计数器代表自启动数据服务器以来的总计数，因此您需要对表进行定期采样，然后使用增量来找出给定时间段内的计数器值（ 例如，拍摄 monSpinlockActivity 的快照，等待1分钟，拍摄另一个 monSpinlockActivity 的快照，获取计数器的差，您将获得过去一分钟的旋转锁活动）。

注意：您需要确保启用自旋锁监视 = 1。

经常弹出的常见原因（CPU使用率很高）是过程高速缓存大小不足。 这将显示在 monSpinlockActivity 中，具有高（增量）旋转/抓取和等待/抓取的值。

--------

几个好的资源：

ASE WIKI页面re：自旋锁和（高 ）CPU使用率（包含用于示例 monSpinlockActivity 的示例代码）

Jeff Tallman的博客回复：调整大小 过程高速缓存（如果您发现真正的问题是与过程高速缓存相关的自旋锁争用，则可能与此有关）

从monSpinlockActivity中选择间隔为1分钟的时间：

SpinlockName抓取 旋转等待等待争用fglockspins 40818673 2310551156 13616664 33.35默认数据缓存-4081864140 588372648 7133812 -0.17 SSQLCACHE_SPIN 274884 7587679 1788 0.65 Resource-> rdbt_spin 10094447 4827526 78312 0.77 tablockspins 12216912 3100127 186391 12294 179 24179 127391 2179 127 179 129 12179 127 129 129 129 129 129 129 129 243 179 127 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 127 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 129 Ides链旋转锁31359003 191883 31202 0.09 Sched Q 317878 75159 4365 1.37 Resource-> rdesmgr_spin 696313 36021 2581 0.37

sysmon.txt

附加的sysmon输出

感谢附加数据（ monSpinlockActivity 和 sp_sysmon ）...

-----------

monSpinlockActivity 数据似乎排除了我对与过程缓存相关的自旋锁争用的担忧，其中 fglockspins 是主要问题：

 SpinlockName抓住旋转等待争用
 --------------------------------------------------  -------------
 fglockspins 40818673 2310551156 13616664 33.35
 

根据我引用的那个Wiki页面， fglockspins 与您在最初的帖子/问题中提到的配置参数有关。

注意：虽然 lock哈希表大小= 65536 似乎有点过分（例如， sp_sysmon 显示的是很小的平均avg链长= 0.00015），但我看不到 这是一个问题。

由于更改配置后您仍然遇到自旋锁争用问题（并导致较高的cpu），所以我想知道系统中是否还有其他问题...

-----------

在其余的 sp_sysmon 输出中，我确实在"磁盘I/O管理"部分下找到了一个令人关注的项目，即所有IO（其中大多数都在写） 正在同步执行... *喜欢*：

完成的磁盘I/O
     异步I/O
       已完成的I/O总数0.0 0.0 0不适用
     同步I/O
       已完成的I/O总数307.9 1.6 55429 100.0％
   ------------------------- ------------ -------------  ---------
   已完成的I/O总数307.9 1.6 55429 

理想情况下，ASE应该与100％异步IO一起运行，因为这允许线程在等待磁盘IO完成时继续工作。

在这一点上，我想知道您是否会看到大量的页/行自旋锁争用，因为在等待同步IO完成时正在保持所述自旋锁？ [SAP技术支持应该能够确认/驳斥这个想法]

我想找出为什么ASE在同步IO上运行（例如，Linux主机未配置为支持异步IO； ASE的 allow sql server异步i/o = 0 [off ]），然后查看如何启用异步IO。

-在ASE启动时，错误日志应包含每个设备的单独消息，以包括该设备是同步启动还是异步启动

-请参阅"配置指南（Unix/Linux）"的"在Linux上启用异步磁盘I/O"部分，以进行系统管理员检查。

-如果可以启用异步IO，请确保查看每个引擎/服务器的最大异步i/os config参数，以确保它们的设置不要太低[默认设置通常是 对于当今的磁盘子系统来说太低了，结果是太低的设置会导致ASE磁盘IO活动的人为瓶颈]

谢谢马克-我们将研究设置

sysmon-082517.txt

谢谢马克-更改了配置以允许异步IO。 最新的运行显示默认数据缓存中的自旋锁争用-我们将在下一步中设置命名缓存--当前默认数据缓存具有32个分区-将分区数设置为64是否有缺点？