标签: vmware

我们开始为 VMware 中的 SQL Server 2016 节点虚拟集群提供一组物理服务器。我们将使用企业版许可证。

我们计划设置 6 个节点，但关于在 CPU 时钟速度与 CPU 核心数方面配置物理服务器的理想方式存在一些争论。

我知道这在很大程度上取决于交易量和存储的数据库数量以及其他特定于软件的因素，但是否有建议的一般经验法则？

例如，双 8 核 3.2 GHz 物理服务器（16 核）是否比双 16 核 2.6 GHz 服务器（32 核）更优惠？

有没有人遇到过进一步深入研究此类主题的白皮书？

我们有一个在 VMware 虚拟机中运行的 SQL Server 2016 SP1 实例。它包含 4 个数据库，每个数据库用于不同的应用程序。这些应用程序都在单独的虚拟服务器上。它们都没有在生产中使用。不过，测试应用程序的人报告了性能问题。

这些是服务器的统计信息：

• 128 GB RAM（SQL Server 的最大内存为 110 GB）
• 4 核 @4.6 GHz
• 10 GBit 网络连接
• 所有存储均基于 SSD
• 程序文件、日志文件、数据库文件和 tempdb 位于服务器的不同分区上
• 阿斯达

用户通过基于 C++ 的 ERP 应用程序执行单屏幕访问。

当我ostress使用许多小查询或大查询对 Microsoft 的 SQL Server 进行压力测试时，我获得了最大性能。唯一的限制是客户端，因为他不能足够快地回答。

但是当几乎没有任何用户时，SQL Server 几乎不做任何事情。然而，人们必须永远等待才能在应用程序中保存任何内容。

根据 Paul Randal 的“告诉我它在哪里受到伤害”查询，所有等待事件中有 50% 是ASYNC_NETWORK_IO.

这可能意味着网络问题，或应用程序服务器或客户端的性能问题。他们甚至都没有以最大能力远程使用他们的资源。大多数情况下，所有机器（客户端、应用程序服务器、数据库服务器）上的 CPU 都在 26% 左右。

网络连接的延迟约为 1-3 毫秒。数据库服务器的 IO 在应用程序正常使用期间的最大写入速度为 20MB/s（平均为 7-9MB/s）。当我进行压力测试时，我的速度最高可达 5GB/s。

缓冲区缓存大小为我们的 ERP 系统 DB 为 60GB，我们的财务软件为 20GB，质量保证软件为 1GB，文档归档系统为 3GB。

我授予 …

关于 SQL Server 虚拟化，一直试图寻找信息是否对将数据设备与日志设备分离到不同的准虚拟 SCSI (PVSCSI) 适配器有积极的性能影响，类似于这里所做的。

在客户端上有一个场景，其中添加了额外的 PVSCSI，并将日志设备分离到新的 PVSCSI，显示出可观的性能提升。然而，怀疑是由于这种分离还是仅仅因为现在存在额外的 PVSCSI。

众所周知，日志磁盘通常以顺序方式写入，而数据磁盘在其 r/w 中遵循更随机的模式，将这两种不同类型的文件放在不同的磁盘上具有性能优势。

但是控制器呢？将这些不同的模式保存在单独的 PVSCSI 控制器中是否也有好处？

任何人都对此有任何见解？

提前致谢

这个问题基本上是这个问题的后续问题：
SQL Server 2016 的奇怪的性能问题

我们现在使用这个系统提高了效率。虽然自从我上一篇文章以来，另一个应用程序数据库被添加到这个 SQL Server 中。

这些是系统统计信息：

• 128 GB RAM（SQL Server 的最大内存为 110 GB）
• 4 核 @2.6 GHz
• 10 GBit 网络连接
• 所有存储均基于 SSD
• 程序文件、日志文件、数据库文件和 tempdb 位于服务器的不同分区上
• 视窗服务器 2012 R2
• VMware 版本 HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools 版本 10.0.9，内部版本 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 2016 年 10 月 28 日 18:17:30 版权所有 (c) Windows Server 2012 R2 Standard 6.3（内部版本 9600）上的 Microsoft Corporation 标准版（64 位）： （管理程序）

我们的系统现在存在重大的性能问题。非常高的 CPU 使用率和线程数：

等待活动监视器的统计数据（我知道它不是很可靠）

sp_blitzfirst 的结果：

sp_configure 的结果：

高级服务器设置（不幸的是只有德语）

MAXDOP …

这很可能不是 SQL Server 问题，但设置似乎只影响 SQL Server 的 BULK INSERTS。

我们最近移动了 VM 硬件，所有移动的来宾都将其虚拟交换机从标准更改为分布式。

然后我开始接收

从网络读取输入流时发生致命错误。会话将被终止（输入错误：64，输出错误：0）

在 BULK INSERT 操作期间在两个 SQL 服务器上。其中一台 SQL 服务器是具有新配置的虚拟机，另一台是物理服务器。两个 BULK INSERT 操作都源自具有新配置的 VM。BULK INSERT 不会每次都失败，它会非常随机。

当我们将虚拟交换机更改为标准交换机而不是分布式交换机时，问题就消失了。

我正在寻找更多关于为什么它不适用于分布式交换机而不是分辨率的解释。我的猜测是 BULK INSERT 操作是串行的，并且使用分布式交换机，数据包通过不同的主机路由，其中​​一些主机可能比其他主机更忙，并且到达目标服务器的时间超过了某个延迟阈值。（注意：在源服务器或目标服务器上发生错误时，Windows 事件日志中没有任何内容）

更新：原来问题是由于 NIC。我们所有的虚拟机都配置了一个 E1000 网卡，它在标准交换机上运行良好。一旦我们转向分布式交换机，我们开始看到大数据传输的问题，而不仅仅是 sql 查询。将 NIC 更改为 VMXNET3 似乎已解决该问题。

我的环境如下： VMWare 5.5激活服务器MS Windows Server 2008R2 Enterprise域和SQL Server 2008 R2 Enterprise。具有光纤通道连接的集中存储。

我的SQL Server DB. 我有 2 个file groups：一个带有实时数据 (FG1)，第二个带有历史数据 (HDG)。

第二个文件组是read-only. 每个月我都会在分区中移动 - 我将新数据（来自上个月）添加到历史数据中。这个过程是自动的。

我们将数据库移至新服务器。最初，我必须手动完成该过程。在此操作期间，我的镜像出现故障（在操作 3 之后 - 请参阅下面的流程流程）并出现以下错误：

在主服务器上：

日志中的第 0 行：

Date        15.6.2015 20:54:11
Log     SQL Server (Current - 16.6.2015 07:55:00)

Source      spid84

Message
Setting database option MULTI_USER to ON for database MYDB.

日志中的第 1 行：

Date        15.6.2015 20:54:11 …

我的理解是，使用 VM 的一大好处是您可以在主机上的虚拟机之间共享资源。因此，您可以拥有一个拥有 120 个 CPU 的主机，并在其上放置 5 个虚拟机，每个虚拟机拥有 32 个 CPU。额外的 CPU 在 VM 之间“共享”，主机根据需要动态分配 CPU。内存也是一样。

我也明白，对于装有 SQL Server 的 VM 来说，这是一个很大的禁忌，但我的 VM 管理员不同意。有没有人以一种或另一种方式有任何证据或文件？

我不知道这是否重要，但我们正在使用 VMWare。

我们在 VMWare 主机中有一个 SQL Server 2012 SP 2 CU 8 实例。操作系统为 Windows Server 2012 R2。

Windows 任务管理器说我们有两个套接字和 8 个虚拟内核。此数字对应于来宾下方的实际硬件。

在任务管理器中，我也无法将视图更改为 NUMA 节点。

在 SQL Server 中仍然只能看到一个 NUMA 节点

来自 Glen Berrys 诊断查询的这个片段也给了我这个信息

EXEC sys.xp_readerrorlog 0, 1, N'detected', N'socket';

SQL Server 检测到 2 个插槽，每个插槽 4 个内核，每个插槽 4 个逻辑处理器，总共 8 个逻辑处理器；使用基于 SQL Server 许可的 8 个逻辑处理器。这是一条情报信息; 无需用户操作。

根据所有这些信息，我可以怀疑我们仅在一个 NUMA 节点上运行，但跨两个套接字运行。

我的问题：

1. 我们只在一个 NUMA 节点上运行是否正确？
2. 即使所有内容都位于一个 NUMA 节点上，这是否会影响性能？
3. 什么组件确切地规定了 NUMA 边界？例如，如果我有一个带两个 Intel E5 处理器的双插槽主板，主板会决定我有多少个 NUMA 节点或处理器。

我认为有很多关于 NUMA 节点的错误信息。如果有人可以回答我的问题或指出详细解释这个概念的有用资源，那将不胜感激。

最近我们学区已经将多台服务器从2005版升级到2016版，从物理服务器升级到VM服务器。

我们的基础架构团队展示了用于 SQL Server 安装的单核 VM 服务器。

我试图向该部门的负责人解释 SQL Server“讨厌”在单核上，而他希望看到“证据”。我提供的数据都不能满足他的证明需要，因此他要求提供一些关于为什么 VM SQL Server 不能在单核上有效运行的文章。

你用什么文章来做这件事？

任何对我的案件的帮助将不胜感激！

我们有一个特定的 SQL Server，它在接受连接时会间歇性地超时。该问题全天都是一致的，但发生率非常低。如何继续排除故障？

连接超时已过期。尝试使用登录前握手确认时超时时间已过。这可能是因为登录前握手失败或服务器无法及时响应。尝试连接到此服务器所花费的持续时间是 - [Pre-Login] 初始化 = 0; 握手=15002；（Microsoft SQL Server，错误：-2）

服务器配置：

• SQL Server 2016 SP1 CU5 Enterprise（SP1 之前也出现过问题）
• 服务器和客户端上的 Windows Server 2012 R2
• HP ProLiant DL360 Gen9 上的 VMware ESXi，6.5.0
• VM 有 8 个 vCPU，64 GiB 内存（完全保留）

测试脚本（每秒执行一次）：

$failed = $false;
$loginDuration = (Measure-Command {
    $ncon = New-Object System.Data.SqlClient.SqlConnection `
        @( 'Data Source=1.2.3.4,16143;Database=Test;User=Test;Password=****;Pooling=false;' );
    try 
    {
        $ncon.Open();

        $cmd = New-Object System.Data.SqlClient.SqlCommand `
            @( 'SELECT @@VERSION', $ncon );
        $cmd.ExecuteNonQuery();

        $ncon.Dispose();
    }
    catch
    {
        $failed = $true;
    }
}).TotalMilliseconds;
Write-Metric …