ITPub博客

首页 > 数据库 > SQL Server > wait_type SOS_WORKER导致数据库连接失败

wait_type SOS_WORKER导致数据库连接失败

原创 SQL Server 作者:ywxj_001 时间:2020-02-17 17:31:29 0 删除 编辑

SQLServer数据库system_health:event_file:

有数据库锁。

数据库日志报错:

The client was unable to reuse a session with SPID 2799, which had been reset for connection pooling. The failure ID is 46. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.

还有wait_type   SOS_WORKER

数据库做统计信息收集导致查询SQL的锁等待,wait_type    LCK_M_SCH_S

最终耗尽数据库线程池的线程,导致数据库会话连接失败。



这个等待类型出现是因为服务器的线程池(Thread Pool)没有可用的线程,它可能导致登录失败或SQL语句无法正常运行。


当任务在等待工作线程(worker thread)运行时出现这个等待事件。这可能表明数据库参数max worker threads的值设置

过低, 或者批处理执行时间过长, 从而减少了可用于满足其它批处理的工作线程(worker thread)数量。(举个生活当中的

例子,当你去饭店吃饭,工作线程好比餐厅的服务员,例如服务员过少或某些顾客占用服务员的时间过长,那么就会出现很

多顾客郁闷地长时间等待服务的现象。)




这个等待类型在sys.dm_xe_map_vlaues中对应的扩展事件为SOS_WORKER




SQL Server实例在启动的时候创建了一定数量的工作线程(workder threads),举个例子, 我的笔记本的CPU有8个逻辑

处理器,因此SQL Server实例启动的时候创建了576个工作线程。你可以从sys.dm_os_sys_info 这个DMV视图中的

max_worker_count列查看你的实例分配了多少工作线程。




在[sys].[dm_os_sys_info]可以查到:


CPU和max_workers_count对应关系(系统自动分配):


CPU 32核对应max_workers_count为960


CPU 64核对应max_workers_count为1472


最大工作线程数为0,表示系统自动分配。(如上根据CPU核数自动分配最大工作线程数)



当一个查询去执行时,SQL Server会决定需要多少个线程,并且决定为线程池(thread pool)保留多少个线程。 

如果没有足够可用的线程,此时threadpool 等待就会出现,如果没有可用的线程, 连接到SQL Server就会失败。




可能有多种原因导致工作线程发生饥饿现象(Worker thread starvation),包括下面一些情况:



一个线程获取了一个锁,然后导致其它线程被阻塞,越来越多的连接出现并被阻塞,最终耗尽了线程池(thread pool)

中的线程。


这种情况可以从sys.dm_os_waiting_tasks 这个DMV视图中(使用我的脚本)找出被单个SPID阻塞的记录,并考虑将其杀死。


并行查询计划正在被数百个连接执行,耗尽了线程池中线程。


查看CXPACKET等待并标识那些并行执行计划的SQL语句,尽可能减少并行的总量发生。


一个查询计划正在被许多连接执行,并且查询时间比平时要长,耗尽了线程池的线程。


查询CXPACKET等待并如何识别偏斜平行度(skewed parallelism)。


还要查找那些长时间运行的查询语句,并调查发生了什么等待以查看是否存在常规性能问题导致线程匮乏,或者那些长时间

运行的SQL语句是否有不正确的查询计划。




SQL Server中的活动会话数等于工作线程数


检查sys.dm_exec_requests视图中的记录数,如果记录数接近工作线程数量, 减少连接数量(例如,应用程序是否没有使

用连接池或没有正确关闭)或增加max worker threads的值。请注意,由于空闲连接不消耗工作线程,因此与SQL Server

连接的数量可能超过活动(Active)的连接,这可能是完全正常的。

dm_exec_requests:包含sleeping状态的会话(真实的数据库会话连接数,占用工作线程)

dm_exec_sessions:不包含sleeping状态的会话


对max worker thread参数的不正确配置。


查看max worker worker thread 选项的值并设置为自动调整。


如果由于工作线程不足(worker thread starvation)无法连接到SQL Server去进行故障诊断,请尝试使用专用管理员连接

(DAC)。


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

请登录后发表评论 登录
全部评论
在零售、金融行业从事数据库相关工作10余年,有丰富的数据库管理的相关经验。 涉及SqlServer、Oracle、MySQL、PostgreSQL等多种数据库。 专注于各类数据库的研究。 目前在一家外资的上市零售公司担任资深DBA岗位。负责整个集团数据库的架构设计和管理。

注册时间:2010-01-19

  • 博文量
    141
  • 访问量
    134829