我已经花了很长时间来排查间歇性的服务器性能问题,但我已经没有什么主意了。我正在寻找任何建议,以便能够找出问题的原因。
几年前,我和我的团队使用 SQL Server 数据库为客户开发了一个客户端/服务器 Windows 窗体应用程序。客户最近开始遇到一些性能问题,并决定升级其基础架构。他们从一台物理 SBS 机器迁移到具有多个 VM 的虚拟环境。我们成功地将应用程序和 SQL 位迁移到新环境。然后,客户要求更新应用程序以修复他们多年来一直存在的一些内存泄漏和其他性能问题/错误。我们进行了更新,系统在我们的环境中的基准测试结果良好。然后我们将其部署到他们的新生产环境中,系统似乎运行良好。
部署一两天后,我们收到了有关系统在加载/保存表单数据或生成报告时挂起或滞后的投诉。我们远程联系了客户并确认了问题。我们分析了客户环境并检查了可能的内存泄漏和其他可能导致症状的问题。我们没有发现任何问题。然后我们意识到性能问题正在影响网络上的多台机器,并且一定是环境问题。然后客户让他们的硬件支持技术人员对源的潜在硬件/网络配置进行故障排除。他们没有发现任何问题。
在与客户一起进行故障排除的过程中,我们偶然发现了在性能问题出现时(似乎是随机出现的)纠正方法。服务器重新启动可以解决问题,但这不是可接受的解决方案。
另一种方法,也是我发布这篇文章的原因,是当客户注意到性能下降时,他们可以打开应用程序的“旧版”版本(在某些客户端计算机上仍然可用),性能就会恢复。无需重新启动现有的客户端应用程序实例。
系统在事故发生之间运行良好,问题似乎平均每 2 到 3 天发生一次,但已运行长达一周而没有发生事故,并且一天内发生多起事故(一次在早上,一次在下午)。
我们认为该问题可能是 SQL Server 问题。因此,我一直在进行分析、保存跟踪,并且还一直在监控 SQL 性能计数器以寻找线索。我不是 SQL 性能专家,因此我可能没有查看正确的计数器,但 SQL Server 似乎并没有受到太大的压力。CPU、内存、每秒批次、每秒事务、每秒编译次数、每秒重新编译次数没有持续峰值,并且分页和缓存计数器通常是静态的。
应用程序可能同时运行 10 到 20 个活动实例。应用程序最初编写时并未采用最高效的数据检索实践,但产生的负载对于服务器来说并不难以处理。
我还一直在监视 Windows 事件日志中是否存在可能对问题有所启发的错误和警告,但没有看到在事件发生之前或期间出现任何指向问题的信息。
我们发现的另一个奇怪的现象是,无论整体系统性能如何,应用程序在服务器上直接执行时性能不会下降。当其他机器遇到问题时,我直接在服务器上运行该应用程序,没有出现任何缓慢或滞后的情况。
抱歉,这本书不好。我会继续挖掘线索,但如果有任何建议,我将不胜感激。
服务器:Windows Server 2012 R2(分配了足够资源的虚拟机) SQL:SQL Server 2014 Standard 客户端:混合但主要是 Windows 7 Professional
答案1
答案2
您有没有想过这个问题?您的应用程序使用哪种连接字符串?如果它在服务器上运行良好但在客户端上运行不正常,请记住网络连接。例如,如果您的连接字符串使用 datasource=computername,那么在服务器上它将使用循环返回,而在客户端上它将使用名称解析和 IP 地址。也许可以尝试在连接字符串中使用 IP 而不是 DNS 名称来消除 DNS 查找。