【发布时间】：2017-11-09 19:13:17
【问题描述】：
我正在为我们的一位客户提供支持，该客户在其所在地的虚拟服务器上拥有我们的企业版 Web 应用程序。他们有 3 个 Web 服务器和 1 个 DB 服务器。所有 4 台服务器都使用 vCenter 进行虚拟化，并安装了 Windows Server 2008 R2。
数据库服务器正在运行具有 36 GB RAM 的 SQL Server 2008 R2，以及在 SAS 设置上用于数据库、日志、备份等的单独驱动器（总共 7 个虚拟），尽管备份发生在 SSD 驱动器上.
每个 Web 服务器都有 4 GB RAM 并且负载平衡。我们有一些流程可以将来自第三方的数据导入我们的最终用户应用程序，但最近其中一个流程在服务器上出现了瓶颈并导致了问题。 应该 花费数小时的进程需要数天，而且经常失败，因此我必须在 SQL 中手动将进程排队并让它运行。
经过大量调查，我不知道这是什么问题。我已经确认所有 Web 应用程序设置都与我们的托管环境相同，它容纳的客户比这大得多，我们的数据库服务器更强大，但服务器上的整体负载非常好。
我包含的一些指标让我担心服务器上实际发生的进程。我已经在下面包含了这些，但我特别担心延迟写入/秒和空闲列表停顿/秒，对我而言，这表明该进程正在使内存中的服务器超载并将页面转储到硬盘，这将驱动性能下降。它是否正确？谁能给我关于从这里去哪里的想法？客户肯定不喜欢向数据库服务器添加更多资源的想法，所以我希望能够明确地证明问题出在哪里。
由于这是在虚拟化环境中，是否也可能是资源恰好被共享，从而降低了 VM 的性能并导致将其刷新到驱动器？任何帮助将不胜感激。我的硬件经验已经达到了极限，而且我不是 DBA，所以我试图用 SQL Server 来了解所有在后台实际发生的事情。
谢谢！
Buffer cache hit ratio 1363657/sec
Buffer cache hit ratio base 1363687/sec
Page lookups/sec 28043473454/sec
Free list stalls/sec 621/sec
Free pages 1438/sec
Total pages 3932160/sec
Target pages 3932160/sec
Database pages 3846600/sec
Reserved pages 0/sec
Stolen pages 84122/sec
Lazy writes/sec 77354/sec
Readahead pages/sec 15305687/sec
Page reads/sec 16859120/sec
Page writes/sec 7751703/sec
Checkpoint pages/sec 5408194/sec
AWE lookup maps/sec 0/sec
AWE stolen maps/sec 0/sec
AWE write maps/sec 0/sec
AWE unmap calls/sec 0/sec
AWE unmap pages/sec 0/sec
Page life expectancy 16434/sec
【问题讨论】：
-
你最好在 dba.stackexchange.com 上问这个问题
-
标记为应该关闭，因为偏离主题 - 与开发无关。您在总结所有内容方面做得很好，但是这个问题太广泛了，无法在 SO 主题中回答。您说备份到 ssd 驱动器，但即使数据库也位于 ssd 上也不行。在专业环境中，我倾向于在服务器达到内存限制一次时添加更多内存。此外，我还需要 VM 主机上的专用内存进行调试。
标签： sql-server sql-server-2008 database-performance