首先是背景故事——
突然（实际上是一夜之间）一个实例开始发出 CPU 使用率警报。这是一个相当低级的 VM（1 个 vCPU，2GB RAM），但它所做的只是非常低级的 NFS 服务和 Cacti 轮询以及为少数系统提供服务。此 VM 托管在 vSphere 4.x 上的 IaaS 提供商处，并位于企业套件（HP/NetApp SAN 等）上。
我最后一次更改此系统上的任何内容是在将近 4 周前。查看指标后发现，McAfee (cma) 使用的提供商代理/进程之一消耗的 RAM 比平时多得多，直到上周末我重新启动了 cron 作业（cron 作业之所以存在，是因为我确信此代理存在内存泄漏）。无论如何，问题是我无法再在此系统上运行 Cacti（运行 poller.php 的 httpd/mysql/php cron 作业） - 负载将超过 10，并且 iowait 非常高（~ 90%）。我尝试了以下方法：
- 在停止 McAfee 服务的情况下运行 Cacti
- 每次尝试运行 Cacti 后，系统地更新 php*、httpd/mod_ssl、mysql-server
- yum 更新所有最新软件包，现在是 RHEL 5.8 (x86_64)
yum update (all) 使系统负载超过 6 并耗费了数小时。
我询问托管提供商存储层是否有问题，但他们说没有。但这根本无法解释。这让我想知道分区错位是否可能存在问题，因为我读到过它可能会导致我似乎遇到的那种症状。现在提供商会在 vSphere/vCenter 客户端中创建这些 VMFS 分区，据我所知，这确保了对齐。但它会随着时间的推移而失去对齐吗？如果是这样，有什么方法可以从 VM/Guest 检测到这一点吗？mbrscan（NetApp）实用程序看起来可以检测到，但必须从主机的 ESX 控制台运行。
谢谢！
编辑：添加了 uS 的 sfdisk 输出：
[root@nfs1 ~]# sfdisk -luS /dev/sda
Disk /dev/sda: 13054 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System
/dev/sda1 * 63 208844 208782 83 Linux
/dev/sda2 208845 164055779 163846935 83 Linux
/dev/sda3 164055780 209712509 45656730 8e Linux LVM
/dev/sda4 0 - 0 0 Empty
更新：
重新启动此实例完全解决了性能问题。托管提供商的进一步分析确实表明存在一些错位，但在他们看来，这不会导致所经历的症状。他们说，例如，Windows VM 中的错位更大。此时，我们将等待，看看它是否会再次发生，如果是，则更改扇区偏移量。
答案1
发现对齐问题的唯一方法是测量主引导记录。如果您可以从虚拟机中进行此操作，则可以查看是否未对齐。
也就是说，对齐问题会增加您对存储执行的 IO 数量，但必须设置一些限制来阻止您执行如此多的 IO。Netapp 尤其受此影响，因为一旦需要后端额外关注的“部分写入”数量达到一定水平，他们就会开始限制性能。其他系统只是将每个 IO 与上一个 IO 相同，因此不会出现 Netapp 遇到的存储延迟大幅飙升的情况。
答案2
您应该能够使用 Linux 上的 sfdisk 找出客户机对齐。只需查看分区的起始扇区即可。 但，这只能告诉您一半的故事，因为您的提供商可以/应该考虑存储层的默认操作系统对齐。
因此，即使看起来在 63 个扇区处未对齐，存储也可能会在 LUN 或数据存储中有一个偏移，以将其纠正为对齐的边界。但至少您可以将新知识告知您的提供商并让他们确认。
更新（针对新的 sfdisk 结果）：您的所有分区均未在相同的 4KB 或 8KB 块边界上对齐，因此您很可能遇到了一些错位问题。您需要询问您的提供商存储使用什么块对齐方式（例如 4KB）以及他们使用什么对齐校正（如果有）。如果他们没有任何对齐校正，您希望所有分区都从可被 8 或 16 整除的扇区数开始。在此过程中，均匀的 1MB 起始偏移（可被 2048 整除）允许将来更改任何底层存储块大小。