sql-server – 为什么要定期重启以保持我的实例运行良好？

我们在SQL 2005上有一个生产数据库服务器.一切正常运行一段时间,但几周后我们看到一个显着的性能下降.只有重新启动SQL Server才能使性能恢复正常.

一些背景：

>运行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团队合作,看看他们是否可以解决问题.

解决方法

我的假设是服务器上的另一个应用程序正在泄漏内存.我已经看到了病毒软件(每个DBA最喜欢的服务器软件恶棍)和第三方监控软件.我会仔细检查SQL Server的内存使用情况,随着时间的推移,我也会抓住盒子上所有其他应用程序的所有内存使用情况.如果您对SQL Server的内存使用设置了硬限制,并将其设置为不允许分页,则可能是其他应用程序被分页并消耗I / O容量.

这不难找.如果你还没有在服务器上保留指标,我会启动Perfmon并让它每隔30或60分钟获取一次样本.几天后,您可能会看到另一个应用程序内存使用量向上蔓延.

SQL Server日志中是否有错误消息指出“sql server的重要部分已被分页”？这也是一个很大的线索.

（编辑：青岛站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!