我一直在解决一个间歇性的服务器性能问题太久，我没有想法。 我正在寻找任何build议，以便我能够找出问题的原因。
我们（我的团队）在几年前为客户开发了一个使用SQL Server数据库的客户端/服务器Windows Forms应用程序。 客户最近开始遇到一些性能问题，并决定升级其基础架构。 他们从一台物理SBS机器迁移到有多台虚拟机的虚拟环境。 我们成功地将应用程序和SQL位移植到了新环境中。 然后，客户端请求应用程序更新以修复多年来一直运行的内存泄漏和其他性能问题/错误。 我们在我们的环境中做了更新和系统平台。 然后，我们部署到他们新的生产环境，系统似乎运行良好。
在部署后的一两天，我们收到有关系统挂起或滞后的抱怨，当加载/保存表格数据或生成报告时。 我们远程与客户端连接并确认问题。 我们分析了客户端环境并检查了可能的内存泄漏以及可能导致症状的其他问题。 我们没有发现。 然后我们意识到性能问题影响到networking上的多台机器，并且必须是环境的。 然后客户有他们的硬件支持技术人员排除潜在的硬件/networkingconfiguration的来源。 他们没有发现。
在我们与客户进行的几轮故障排查中，我们偶然发现了纠正性能问题的方法（这似乎是随机的）。 服务器重新启动修复了这个问题，但这不是一个可接受的修复方法。
另一种方式，也是我发布这个的原因是，当客户端注意到性能下降时，他们可以打开应用程序的“传统”版本（在某些客户端机器上仍然可用），性能得到恢复。 现有的客户端应用程序实例重新启动是不需要的。
这个系统在事件之间performance良好，这个问题似乎平均每2到3天就会发生一次，但是一个星期内无事故发生，并且在一天内也有多起事件（早上一次，然后一次这个下午）。
我们认为这个问题可能是一个SQL Server问题。 所以我一直在分析，保存痕迹，并一直在监视SQL性能计数器寻找线索。 我不是SQL性能专家，所以我可能不会考虑正确的计数器，但SQL Server似乎并没有被推得很辛苦。 CPU，内存，批次/秒，事务/秒，编译/秒，重新编译/秒，并且寻呼和caching计数器通常是静态的。
应用程序可能一次运行10到20个活动实例。 应用程序最初并不是用最有效的数据检索实践编写的，但是生成的负载不是服务器无法处理的。
我也一直在监视Windows事件日志中的错误和警告，可能会发现问题的一些亮点，但没有看到任何事件之前或事件中指出的问题。
我们发现的另一个奇怪的观察是，无论系统整体性能如何，直接在服务器上执行应用程序时，应用程序都不会降级 当其他机器遇到问题时，我已经直接在服务器上运行应用程序，没有缓慢或滞后。
对不起，这本书。 我将继续挖掘线索，但任何build议将不胜感激。
服务器：Windows Server 2012 R2（分配大量资源的虚拟机）SQL：SQL Server 2014标准客户端：混合但大部分为Windows 7 Professional
就数据库而言，我会开始将活动logging到一个表中， 像这样 。 您需要调整存储的proc以运行更长的时间，以便数据不断logging（SET @numberOfRuns = 10），或放弃完全检查。
有一些工具可以使服务器性能日志分析更容易。 这是一个。 这是作者的博客 。
当问题发生时，您可以尝试使用networking监视器来查看客户端正在发生的情况。 还要看看服务器上的perfmon中的NICstream量计数器。 当netstat问题发生的时候检查一下tcp会话。 我对networking知之甚less，所以这可能是盲目领导盲目的情况:)
你有没有解决这个问题？ 你的应用程序使用什么样的连接string？ 如果它在服务器上运行良好，但不在客户端上，请记住networking连接。 即如果您的连接string使用datasource = computername，那么在服务器上它将使用循环返回，并在客户端上，它将使用名称parsing和IP地址。 也许尝试使用连接string中的IP而不是DNS名称来消除DNS查找。