SQL Server 2008 R2执行存储过程sp_MailItemResultSets引起大量PREEMPTIVE_OS_WAITFORSINGLEOBJEC等待

 

从监控工具dpa中发现一个数据库（sql server 2008 r2）的等待事件突然彪增，下钻分析发现数据库执行存储过程sp_mailitemresultsets时，引起了非常严重的等待(high wait)，而主要的等待事件为preemptive_os_waitforsingleobjec。 如下截图所示:

 

 

查询正在执行的sql，发现会话正在执行下面sql(存储过程sp_mailitemresultsets中的一个sql语句)，等待事件为async_network_io。  

 

use msdb;

go

select 

      mi.mailitem_id,

      mi.profile_id,

      (select name from msdb.dbo.sysmail_profile p where p.profile_id = mi.profile_id) as 'profile_name',

      mi.recipients,

      mi.copy_recipients,

      mi.blind_copy_recipients,

      mi.subject,

      mi.body, 

      mi.body_format, 

      mi.importance,

      mi.sensitivity,

      isnull(sr.send_attempts, 0) as retry_attempt,

      isnull(mi.from_address, '') as from_address,

      isnull(mi.reply_to, '')     as reply_to

   from sysmail_mailitems as mi

      left join sysmail_send_retries as sr

         on sr.mailitem_id = mi.mailitem_id 

   where mi.mailitem_id = @mailitem_id

 

 

 

关于async_network_io与preemptive_os_waitforsingleobjec的关系如下：

 

这个等待事件表示一个线程正在向外部客户端进程同步某个对象的数据，因此出现此种等待。而且通常和async_network_io等待事件同时出现。根据我的观察，查询正在执行的sql，等待事件为”async_network_io“而并非”preemptive_os_waitforsingleobjec“

 

 

关于这个等待事件的更多详细信息，具体见链接“preemptive_os_waitforsingleobject”，当前数据库版本为sql server 2008r2

 

description:

 

this wait type is when a thread is calling the windows waitforsingleobject function for synchronization with an external client process that is communicating using that object.

 

other information:

this wait type is commonly seen in conjunction（同时出现） with async_network_io, depending on the network transport used to communicate with the   client, so to troubleshoot, follow the same steps as for async_network_io.

 

note that when a thread calls out to windows, the thread changes from non-preemptive (sql server controls the thread) to preemptive (windows controls the thread) mode. the thread’s state will be listed as running, as sql server doesn’t know what windows is doing with the thread.

 

 

 

确实是一个非常奇怪的现象，然后我又去检查系统的应用日志，结果发现大量的错误：

 

错误信息比较奇怪，让人摸不着头脑，也没有看到有相关资料介绍，主要有下面两种错误：

 

1：database engine instance=xxxxx;mail pid=7248;error message:the connection is not open.

 

2: database engine instance=xxxxx;mail pid=7248;error message:exception of type 'system.outofmemoryexception' was thrown.

 

 

验证sql语句性能， 发现sql语句的确非常慢，从执行计划来看，没有什么异常情况，而且这个也是系统数据库，不应该存在一些索引问题。

 

 

 

但是检查dbo.sysmail_mailitems表，发现此表记录数为2722，但是表的大小接近8g了。非常不正常。对比了其它几个数据库服务器，发现这个表非常小。检查邮件记录里面是否有大量附件。也没有发现有大量附件。

处理问题的时候，没去定位是那条或那些记录占用了大量空间。急着解决问题，放弃分析这些情况了。可惜了！

 

 

 

 

官方也没有相关资料，只能猜测是因为dbo.sysmail_mailitems的大小引起了性能问题，然后我尝试用下面sql清理这个表的记录

 

/******************************************************************************************************

    script function        ：    以下示例删除数据库邮件日志中所有失败的电子邮件

*******************************************************************************************************/

execute msdb.dbo.sysmail_delete_mailitems_sp   

    @sent_status = 'failed' ;  

go 

/******************************************************************************************************

    script function        ：    以下示例删除数据库邮件系统中的所有电子邮件

*******************************************************************************************************/

declare @getdate datetime  

set @getdate = getdate();  

execute msdb.dbo.sysmail_delete_mailitems_sp @sent_before = @getdate;  

go  

 

 

最后清理过后验证发现，这个存储过程的确非常快了，数据库中该等待事件直接消失了。系统应用日志中关于mail pid的错误也消失了。后续观察发现，这个表也变得特别小了，完全没有之前那么大了。