标签: vmware

这是一个需要大修的客户端环境，所以我要做的就是减缓流血。

情况

CPU 被压垮了，通常是 80% 或更高的利用率

VMWARE 5.5、Windows Server 2008r2、SQL Server 2012

1 个具有 6 核的 vCPU（此处为红旗）

70GB 内存

16 个独立的实例，驱动大部分 CPU 使用的实例有 80 个用户数据库

所有大多数实例 MAXDOP 0，所有并行成本阈值为 5

中断现在不是一个选项，所以没有重新启动，没有 vCPU 更改，但我需要减缓高 CPU 的出血。

这是前 10 个当前等待具有 80 个 DB 的实例的示例，CPU 猪：

??????????????????????????????????????????????????????????????????????
?      wait_type       ? Wait Time (Secs) ? # of Waits ? Avg ms/Wait ?
??????????????????????????????????????????????????????????????????????
? WRITELOG             ? 9.8              ? 5563       ? 1.8         ?
? PAGELATCH_SH         ? 7                ? 21742      ? 0.3         ?
? SOS_SCHEDULER_YIELD  ? 6.5 …

我的数据库版本是postgresql 9.5。

create table if not exists request_log
(
    id               bigserial not null constraint app_requests_pkey  primary key,
    request_date     timestamp not null,
    ip               varchar(50),
    start_time       timestamp,
    application_name varchar(200),
    request_path     text,
    display_url      text,
    username         varchar(50)
);

我有一个包含传入 http 请求信息的表。该id列是主键和索引。表没有关系。

所以这个表中有 72320081 行。当我运行计数查询来获取表的计数时，select count(id) from request_log;查询需要 3-5 分钟。

explain(analyze, buffers, format text)该请求的结果是：

Aggregate  (cost=3447214.71..3447214.72 rows=1 width=0) (actual time=135575.947..135575.947 rows=1 loops=1)
  Buffers: shared hit=96 read=2551303
  ->  Seq Scan on request_log  (cost=0.00..3268051.57 rows=71665257 width=0) (actual time=2.517..129032.408 rows=72320081 loops=1)
        Buffers: shared …

昨天我们讨论了性能和可恢复性，我意识到虚拟化环境可以给我带来多少好处 - 但由于我对性能有点怀疑，所以我在这里问。它可能是特定于 GIS 的，但是在 gis 用户那里，他们说这是特定于数据库的......;)

数据库服务器是否会因虚拟化而遭受严重的性能损失？我不了解这项技术的最后细节，但不知何故，它更像是一个“黑匣子”，需要通过硬件进行处理。磁盘访问以及 PostGIS 为我们提供的所有技巧是否会被授予？（聚类、索引等） - 碎片聚类就像没有聚类！

最大的优势是可维护性和可扩展性。如果发生严重的硬件故障，我可以在几分钟内甚至实时迁移到另一台物理机器。

谁有经验，可以给我指点关于这个主题的好的网站或文献？我记得上次 fossgis 中的一些事情以及 ESXi 和本机服务器上的一些内部基准测试，不知何故我无法确定它是否好。

我最近将一个物理 SQL Server 机器 (2012) 迁移到 ESX (5.1)，只是为了便于管理。它是并且将是服务器上唯一的来宾。正如预期的那样，在大多数情况下只有在启动时才会出现边际性能下降。这就是我的问题。

我注意到，在虚拟化下，缓冲池占用的内存比其物理对应物慢得多。

在 2 天内运行 SQL 服务器的物理安装已分配所有 120GB 的内存分配（最大服务器内存）。但是，在虚拟机管理程序中运行几乎完全相同的设置（我还为来宾提供了完全保留的内存），它花了 7 周的时间才达到 50GB。这也是令人痛苦的缓慢，例如每天 Gb 上升，这转化为几天的缓慢查询。

因此，虽然我在多客人盒子上看到过这种情况并将其归因于内存压力，但我对为什么在单个客人盒子上发生这种情况感到困惑。我知道 vmware 会压缩和重复数据删除内存，但是其中大部分是唯一数据。

所以我的问题是：

1) 为什么会发生这种情况？我对导致这种情况的确切机制感兴趣。

2) 有没有一种方法可以在完全内存分配的情况下启动 SQL 服务器？我记得类似跟踪标志的东西，但还没有找到 64 位的任何东西。这是必要的吗？

提前致谢。

我在重新启动后的前几天注意到的另一件事是 PLE 在 500 - 900 范围内保持非常低，这会随着缓冲池的增长而增加。

我有一个用于共享点和 ssrs 的 SQL Server 2008 R2。SQL Server 承载两个实例。

有几分钟，两个实例都超时了，没有响应。

CPU 缓慢上升到 100%，两个实例均为 30%，操作系统为 30%（以及一些较小的东西）。

之后，16GB 的内存未从 SQL Server 分配，一些进程使用了​​几 GB 的内存（在 esxi 上不知道是哪个）。

此后，SQL Server 再次拥有最大内存量，PLE 大约为 15000。

我想知道的是，如何跟踪 SQL Server 被迫放弃内存的原因？

跟踪文件中某处的历史记录，还是 Windows 事件？（到目前为止我都击中了）

我试过：

DECLARE @log NVARCHAR(100)
SELECT @log = Substring(PATH, 1, Len(PATH) - Charindex('\', Reverse(PATH))) + '\log.trc'
FROM   sys.traces
WHERE  id = 1
SELECT 
    g.DatabaseID,
    g.LoginName,
    g.StartTime,
    g.EndTime,
    g.DatabaseName,
    g.FileName,
    e.name
FROM  ::fn_trace_gettable(@log, 0) as g
inner join sys.trace_events e on g.eventclass = e.trace_event_id 
inner join …

我以前从未见过这种情况，尽管这可能很常见。我正在查看虚拟化 (VMWare 5.5) SQL Server（Windows 2008 R2 上的 2008R2）。我看到的是，在任务管理器 * 中，sqlserver.exe使用了大约 163 MB 的 RAM，如果我使用procexp，则相同的服务显示使用的 RAM 不到 500 MB。

VM 有 32GB 的 RAM，任务管理器显示正在使用该 RAM 的 31.7GB。VMWare Perfmon 计数器似乎没有指示任何膨胀（也许我读错了一些东西）。

想法/指导表示赞赏。我正在尝试调整新 SQL VM 的大小。此时，我还没有获得对 vSphere 或 vCenter 数据库的访问权限。

* 使用任务管理器是因为我正在查看整体内存利用率，而不仅仅是 SQL Server。一位性能敏感的管理员警告我要让我的脚步保持非常轻松。

我有一个在 VM 上运行的数据库，该数据库在大负载期间受到重创，特别是我可以看到 WRITELOG 正在等待。我最初的想法是将文件拆分到它们自己的驱动器上，但后端存储与其他数据库文件所在的位置相同。

基本上，它是作为集群共享卷呈现给整个虚拟机主机的 SAN。

这样做会有性能优势吗？我大脑深处的一些记忆告诉我一些关于 IO 流数量可能会更好的信息？

为了更新这个，我现在已经分离出文件并正确调整事务日志的大小。我一直在收集信息，sys.dm_io_virtual_file_stats并且可以看到我现在拥有极高的 readIOstalls，但具有 13ms 的低延迟。我还收集了一些内存信息，PLE 平均数以千计，这是一个 32GB 的系统，我预计除了在 30 分钟内它下降到 30 之后再次急剧上升之外，此时懒惰写入/秒增加在减少到 0 之前也到 50。这段时间可能是我看到的大量读取停顿的原因吗？我会期望看到如此高的读取停顿和高延迟吗？

我们在 Linux 上的 VMWare 下运行 MySQL 5.5，在 2 个 CPU 上运行。我们计划将其增加到 4，但我们有未使用的 CPU，我想知道将数量增加到 8 是否有任何好处？

您认为就虚拟来宾套接字/CPU 配置而言，实现最佳 SQL Server 性能的最佳配置是什么？我读过很多文章，指出宽插槽配置（每个插槽 1 个 cpu）可提供最佳性能。在其他文章中，SQL Server 的最佳性能是通过 1 个插槽和该插槽中的“x”个 cpu 来实现的。将来宾 VM 套接字/CPU 与物理主机配置相匹配。

SQL Server Standard 仅限于 4 个套接字，但您发现哪种配置性能最佳？我们计划在不久的将来进行负载测试。我期待您的反馈。提前致谢！！！

一段时间以来，我们在运行 SQL Server 的虚拟环境中遇到了一些奇怪的问题。

我们从用户那里随机收到关于 SQL 盒性能非常差的电话。果然，当我查看时，我看到 CPU 固定在 100%。我对另一台主机执行 VMotion，一旦它完成移动到另一台主机，性能立即恢复正常。

我一直在与 VMWare 管理员合作，他们向我保证 VMotion 不会影响 SQL Server 上的任何内容。就好像移动到另一台主机会导致执行计划更改等。然而，我不明白为什么 CPU 使用率突然飙升，除非由于参数嗅探而导致重新编译的查询计划很糟糕，但我认为 VMotion 不会解决这个问题，因为它应该是透明的。

VM 场由 19 台戴尔服务器（抱歉，我不知道确切型号）组成，每个服务器有 2 个物理插槽和 12 个内核。

以前有没有其他人观察过这种行为？我想知道这是否与容量有关，因为似乎有一些大型 VM 供主机处理（有 14 个 80GB、12 个核心 VM 浮动）。即使在场中使用这些虚拟机，我也可以在 Vsphere 控制台中看到主机没有被过度使用（内存确实在很多时候爬升到 80% 标记，但没有膨胀）。

此外，这会发生在所有不同版本的 SQL（2008、2008R2、2012 和 2014）上。

非常感谢您的任何见解！

我很确定我明白这一点，但我想确定我明白。我们有一个 SQL Server 2016，它运行着 2 个 NumaNode，每个 NumaNode 有 8 个 vCPU。最大并行度 (MAXDOP) 设置为 8。

这对我来说听起来不对。第一个问题：这是一个像我认为的那样糟糕的想法吗？

根据我的研究，我需要告诉他们减少 VM 设置以使其在单个 NUMANode 中运行。我们似乎遇到了一些随机时期，其中运行时间为 170 毫秒的查询现在超时时间为 30 秒以上！因此，我们快速查看了一下，CPU 使用率为 5%，磁盘 I/O 使用率较低，网络使用率合理......基本上，机器处于空闲状态。我们还查找了等待锁的查询，并且没有。我们正在 AG 组中的辅助节点上运行查询（只读查询）

所以，我的猜测是：它已经获得了足够的负载，可以在第二个 NUMANode 中的一个 vCPU 上切换并运行一个有问题的视图（每天运行大约 4,000 次），然后决定执行计划应该始终运行在那个节点。结果是它正在访问的所有数据都缓存在另一个节点的内存中，并且它需要通过节点间链接（远程内存）来获取它，所以它这样做了，但最终速度慢了很多（170次？），并且查询现在都在这个远程链接上运行越来越多的查询......直到它总是超时，因为远程内存已饱和......

这样的分析有效吗？我不想将其作为解决方案来提交，以解释为什么如果这完全不正确，查询会突然及时跳转。而且很难让他们相信 8 个 CPU 会比 16 个 CPU 获得更好的性能。

哦，还有更多证据来支持我的说法：如果我select * into #tmp from myView OPTION (MAXDOP 16)这样做，我的性能变化约为 -5% 到 -12% - 这意味着运行查询所需的时间比我只使用 8 个 vCPU 时要长。然而，情况并非如此。

所以我的问题是：我的分析是否有效？

更新：还有其他一些事情，我从以下位置获得了很多信息：https://codenotary-compliance.medium.com/vmware-vsphere-why-checking-numa-configuration-is-so-important-9764c16a7e73

其次，如果我执行select * from sys.[dm_os_nodes] then 我得到foreign_commited_KB为5,414,260或5 GB，从上面的信息来看，这听起来像是从另一个节点提交的（这很糟糕？）