一些背景：

>运行1200多个数据库(主要是单个租户,一些多租户).在任何人讲授转移到多租户之前,有正当理由保持这种结构……
> RAM为16 GB.重新启动后,sql Server恢复到15 GB的使用时间不会太长.
>活动数据库连接大约有80个连接 – 考虑到每个进程每个Web服务器有一个连接池,我们认为这是相当健康的 – 因此我们没有连接泄漏问题.

我们在非高峰时段尝试了几件事：
– 运行DBCC DROPCLEANBUFFERS(带有CHECKPOINT)以清除数据高速缓存.它没有任何效果,也没有清除任何RAM使用情况).
– 运行FREEPROCCACHE和FREESYSTEMCACHE以清除查询计划和存储的proc缓存.没有效果.

显然,在活动的生产环境中重新启动sql Server并不理想.我们错过了一些东西.还有其他人经历过吗？

更新：4月至28日
仍然在与这个问题作斗争.我已经将sql Server的内存降低到10 GB,只是为了排除与操作系统的任何争用.我越来越接近缩小范围了,但下一步需要一些帮助.

这是我发现的,重新启动sql Server后,页面文件在12.3 GB和12.5 GB之间徘徊.它会保持这种状态好几天.总服务器线程将在850和930之间挂起 – 在几天内也是稳定且一致的(sqlserver在55到85之间稳定地取决于流量).

然后,有一个“事件”.我不知道这个事件是什么,我无法在日志中看到它,而且我看不到在星期几或时间发生时的任何一致性,但所有突发的页面文件跳转到14.1或14.2 GB,并且线程跳到1750和1785之间.

当发生这种情况时检查perfom,这些线程中有900多个是sqlserver.所以我去sp_who2看看这些线程来自哪里……而且只有使用过的80个左右的数据库连接.

那么….有没有人有任何想法如何找到sql服务器上其余900个线程的位置,以及它们在做什么？

更新：2012年6月1日
仍然在与这个问题作斗争.对于仍在阅读此内容的人来说,线程跳跃的问题已得到解决.这是由自动修改的ComVault备份软件引起的.它正在创建一个线程,试图备份不再存在的数据库(它维护以前的数据库列表)而不是仅备份当前数据库.

但是 – 问题仍然存在,我们必须每周重新开始,给予或花几天时间.与Rackspace团队合作,看看他们是否可以解决问题.