本周我遇到了 MSSEARCH 等待类型的问题，但还无法完全诊断出该问题。
该服务器已经运行了几个星期，没有任何问题，直到前几天，它突然开始花费很长时间来响应用户的请求。
我和我的团队很快发现问题出在全文搜索组件上，但我们不知道是什么原因造成的。（FTS 是我们工作量中大量使用的功能，到目前为止我们没有遇到任何问题。）
我们尝试重新启动 MSFTE 服务，但它没有响应。
如上面的截图所示，服务器的等待任务数略低于 400 个（正常工作负荷量低于 10 个），并且还在增加。
由于服务器正在生产中运行，在重新启动服务器之前我没有太多时间尝试诊断它，所以在整个服务器重新启动后我只剩下 SQL Server 的日志和几个 MSFTE 内存转储。
我希望能够更好地理解这些问题，但我无法从中获得太多信息，所以如果有人能提供指点或阐明这一点，我会非常高兴。
我们能够推断出的只是全文搜索服务已停止工作，但我在网络上没有发现此类错误的证据，尽管现在它似乎运行正常，但我希望真正了解发生了什么并防止它再次发生。
谢谢。
答案1
首先，这是 SSMS 2008 的屏幕截图；）
FTE 对资源的要求与普通数据库存储有很大不同；您应该设置远程 Windows 性能计数器捕获，至少捕获以下计数器：
- CPU 利用率
- 每个磁盘的物理磁盘 I/O（每秒读取/写入）
- 服务器工作队列
- 每个磁盘的平均磁盘队列长度
还有一些相关的 MSSQL 计数器，不过您需要一个正在运行的 MSSQL 实例才能远程设置这些计数器的捕获。如果您没有，则需要在 SQL 服务器上创建集合并导出/导入计数器。
每隔一分钟左右捕获一次这些数据，任何趋势都将很容易发现。
答案2
我们还无法完全诊断问题，但我们确实采取了措施避免这种情况再次发生，我想在这里记录下来。
首先，我们在系统活动较少的时期、数据库维护期间设置了全文索引和全文目录填充，我们不再让系统自动处理它。
其次，我们现在更加密切关注全文搜索服务，关注它们的性能以及 FTS 占用的资源量。我们记录了它的使用情况，并监控了它的文件大小和 I/O 等。
第三，我设置了几个警报，以便操作员 (DBA) 在出现问题时收到通知（并且错误的这是相对的。在我们的例子中，当 FTS 开始使用比其应有的更多的资源时，加上一个合理的阈值。）
到目前为止还没有再次发生（距离第一次发生已经过去近一个月），但如果发生，我们已准备好采取行动，最好是在我们的用户受到影响之前。