主持人 > 博客 > 管理 > 大量可用 RAM、NVMe Intel P4500 和一切都非常慢 - 添加交换分区不成功的故事

大量可用 RAM、NVMe Intel P4500 和一切都非常慢 - 添加交换分区不成功的故事

在这篇文章中，我将讨论我们的 VPS 云中的一台服务器最近发生的一个情况，这让我困惑了几个小时。 我已经对 Linux 服务器进行配置和故障排除大约 15 年了，但是这个案例根本不适合我的实践 - 在我能够正确确定问题原因并解决它之前，我做了几个错误的假设并且变得有点绝望。

前言

我们运营一个中型云，该云基于具有以下配置的标准服务器构建：32 个内核、256 GB RAM 和 4500TB PCI-E Intel P4 NVMe 驱动器。 我们非常喜欢这种配置，因为它通过在 VM 实例类型级别提供正确的限制，消除了对 IO 开销的担忧。 因为 NVMe 英特尔 请在4500月XNUMX日至XNUMX日来台北台湾参观我们的展位PXNUMX。 具有令人印象深刻的性能，我们可以同时为机器提供完整的 IOPS 配置，并为备份服务器提供零 IOWAIT 的备份存储。

我们是那些不使用超融合SDN和其他时尚、时尚、年轻的东西来存储VM卷的老信徒之一，认为系统越简单，在“主要大师已经走了”的情况下就越容易排除故障到山里去。” 因此，我们将 VM 卷以 QCOW2 格式存储在 XFS 或 EXT4 中，部署在 LVM2 之上。

我们用于编排的产品 Apache CloudStack 也迫使我们使用 QCOW2。

为了执行备份，我们将卷的完整映像作为 LVM2 快照（是的，我们知道 LVM2 快照很慢，但 Intel P4500 也可以帮助我们）。 我们的确是 lvmcreate -s .. 并在帮助下 dd 我们将备份副本发送到具有 ZFS 存储的远程服务器。 这里我们还是稍微进步一下——毕竟ZFS可以以压缩的形式存储数据，我们可以使用以下命令快速恢复它 DD 或使用以下命令获取单独的虚拟机卷 mount -o loop ....

当然，您可以不删除 LVM2 卷的完整映像，而是将文件系统挂载到 RO 并复制 QCOW2 映像本身，但是，我们面临这样一个事实：XFS 会因此而变坏，而且不是立即变坏，而是以一种不可预测的方式变坏。 我们真的不喜欢虚拟机管理程序在周末、晚上或节假日由于不清楚何时发生的错误而突然“卡住”。 因此，对于XFS我们不使用快照挂载 RO 要提取卷，我们只需复制整个 LVM2 卷即可。

在我们的例子中，备份到备份服务器的速度由备份服务器的性能决定，对于不可压缩数据，备份服务器的性能约为 600-800 MB/s；另一个限制因素是备份服务器连接的 10Gbit/s 通道到集群。

在这种情况下，8 个虚拟机管理程序服务器的备份副本同时上传到一台备份服务器。 因此，备份服务器的磁盘和网络子系统速度较慢，不允许管理程序主机的磁盘子系统过载，因为它们根本无法处理例如 8 GB/秒，而管理程序主机可以轻松处理该速度。生产。

上述复制过程对于进一步的故事非常重要，包括细节 - 使用快速 Intel P4500 驱动器、使用 NFS 以及可能使用 ZFS。

备份故事

在每个虚拟机管理程序节点上，我们都有一个大小为 8 GB 的小型 SWAP 分区，并且我们使用以下命令“推出”虚拟机管理程序节点本身 DD 从参考图像。 对于服务器上的系统卷，我们在 LSI 或 HP 硬件控制器上使用 2xSATA SSD RAID1 或 2xSAS HDD RAID1。 一般来说，我们根本不关心里面有什么，因为我们的系统卷以“几乎只读”模式运行，除了交换之外。 由于我们的服务器上有大量 RAM，并且有 30-40% 空闲，因此我们不会考虑 SWAP。

备份过程。 这个任务看起来像这样：

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

注意 ionice -c3，其实这个东西对于NVMe设备来说完全没用，因为它们的IO调度器设置为：

cat /sys/block/nvme0n1/queue/scheduler
[none]

然而，我们有许多具有传统 SSD RAID 的遗留节点，这对他们来说是相关的，因此他们正在迁移 AS IS。 总的来说，这只是一段有趣的代码，它解释了无效性 ionice 在这种配置的情况下。

注意旗帜 iflag=direct 为 DD。 我们使用绕过缓冲区缓存的直接 IO 来避免读取时不必要的 IO 缓冲区替换。 然而， oflag=direct 我们不这么做是因为我们在使用 ZFS 时遇到了性能问题。

我们已经成功使用这个方案好几年了，没有出现任何问题。

然后事情就开始了...我们发现其中一个节点不再备份，而前一个节点的 IOWAIT 高达 50%。 当试图理解为什么不发生复制时，我们遇到了以下现象：

Volume group "images" not found

我们开始思考“Intel P4500的末日已经到来”，然而，在关闭服务器更换驱动器之前，仍然需要进行备份。 我们通过从 LVM2 备份恢复元数据来修复 LVM2：

vgcfgrestore images

我们启动了备份，看到了这幅油画：
大量可用 RAM、NVMe Intel P4500 和一切都非常慢 - 添加交换分区不成功的故事

我们再次感到非常悲伤 - 显然我们不能像这样生活，因为所有 VPS 都会受到影响，这意味着我们也会受到影响。 发生了什么完全不清楚—— iostat 表现出可怜的IOPS和最高的IOWAIT。 除了“让我们取代 NVMe”之外没有其他想法，但一个洞察及时出现。

逐步分析情况

历史杂志。 几天前，需要在该服务器上创建一个具有 128 GB RAM 的大型 VPS。 看起来内存足够了，但为了安全起见，我们又分配了 32 GB 给交换分区。 VPS 已创建，成功完成其任务，事件被遗忘，但 SWAP 分区仍然存在。

配置功能。 对于所有云服务器该参数 vm.swappiness 已设置为默认值 60。 SWAP是在SAS HDD RAID1上创建的。

发生了什么（根据编辑）。 备份时 DD 产生大量写入数据，这些数据在写入 NFS 之前被放置在 RAM 缓冲区中。 制度核心，政策引导 swappiness，正在将许多 VPS 内存页面移动到交换区域，该区域位于慢速 HDD RAID1 卷上。 这导致 IOWAIT 增长非常强劲，但不是由于 IO NVMe，而是由于 IO HDD RAID1。

问题是如何解决的。 32GB 交换分区被禁用。 这花了 16 个小时；您可以单独阅读有关 SWAP 如何以及为何关闭如此缓慢的信息。 设置已更改 swappiness 等于一个值 5 遍布云端。

这怎么可能不会发生呢？。 首先，如果 SWAP 在 SSD RAID 或 NVMe 设备上，其次，如果没有 NVMe 设备，但速度较慢的设备不会产生如此大的数据量 - 具有讽刺意味的是，问题的发生是因为 NVMe 太快了。

之后，一切开始像以前一样工作 - IOWAIT 为零。

来源： habr.com

添加评论