Server挂起的查询- tempDb pagelatch_up 2:1:2
我在MS 2014 db上有性能问题。选择的存储过程将输入参数作为自定义表值参数类型。当时有50-100个会话，执行存储proc可能需要1s到14s。我可以用简单的输入参数来执行SP，如果我重复相同的话，它可能需要1s，如果我感到幸运或不幸运的话，它几乎可以占用14s。
运行诊断查询时，我可以看到对这个存储过程的许多调用都是PAGELATCH_UP，并且有一个会话id链在等待另一个会话id。PAGELATCH_UP的格式是资源2:1:2 : 2:6:2 : 2:9:2取决于捕获的时间。所以2:：是tempDb :1:还是6:是tempDb文件，其中有8个，这是128 of 32核心机器。对于最后一个::2我可以发现它是全球分配地图(GAM)。
在所有博客中，人们通常对资源::1或:3 (PFS和SGAM)有异议，但没有看到任何关于GAM的内容。
微软建议如何解决tempDB中的争用问题，该建议侧重于PFS和SGAM：https://support.microsoft.com/en-gb/help/2154845/recommendations-to-reduce-allocation-contention-in-sql-server-tempdb-d。
您是否建议将tempDb文件的数量从8份增加到12份，16份，...32？
这是表值参数的问题吗?这是pagelatch_up的原因，因为这是SP中的select语句吗？
表值参数是否有其他替代？
回答 1
Database Administration用户
发布于 2020-12-03 08:49:14
是表值参数的问题吗?这是pagelatch_up的原因，因为这是SP?
中的select语句。
表值参数在tempdb数据库上创建一个活动，因此，您的存储过程可能会导致tempdb分配争用。此问题的主要症状是在tempdb数据库中看到以下等待类型；
- PAGELATCH_UP
- PAGELATCH_SH
- PAGELATCH_EX
通常，您可以解决此问题以创建多个tempdb数据文件，因为您的Server版本可能用于-T 1117和-T 1118标志。
表值参数的其他替代品吗？
另一方面，使用内存优化的表变量可以使用内存优化表类型和表变量解决这类问题。
你会建议把tempDb文件的数量从8个增加到12个，16个，...32?
这是最佳做法：
TempDB数据文件的数量应该与安装Server实例的机器上最多8个文件的逻辑处理器数量相匹配。
但是，此值可以根据您的需求进行更改。
https://dba.stackexchange.com/questions/280792
复制相似问题
腾讯云开发者
