首先是背后的故事 –
突然之间（实际上一夜之间）一个实例开始抛出CPU利用率警报。 这是一个相当低的虚拟机（1个vCPU，2GB RAM），但它所做的只是非常低的NFS服务和Cacti轮询，并为less数系统提供服务。 此虚拟机托pipe在vSphere 4.x的IaaS提供程序上，位于企业工具包（HP / NetApp SAN等）上。
上一次我在这个系统上做了什么改变，差不多是在4个星期前。 查看指标McAfee（cma）使用的提供商的代理/进程之一消耗了比平常更多的RAM，直到一个cron作业，我已经在周末之前重新启动了服务（cron作业就在那里，因为我相信这个代理有一个内存泄漏）。 无论如何，问题是我不能在这个系统上运行Cacti（运行poller.php的httpd / mysql / php cron作业） – 负载将超过10，而iowait是非常高的（〜90％）。 我已经尝试了以下内容：
yum update（all）将系统置于6的负载下并花费数小时。
我问托pipe服务提供商，如果存储层有什么问题，但他们说没有。 但是这只是不计算。 这让我想知道是否可能有分区错位的问题，因为我读过它可能会导致我似乎遇到的那种症状。 现在，提供者将在vSphere / vCenter客户端中创build这些VMFS分区，我知道这将确保alignment。 但随着时间的推移它会不会一致？ 如果是这样，有没有办法从虚拟机/客户，你可以检测到这一点？ mbrscan（NetApp）实用程序看起来像检测到，但必须从主机的ESX控制台运行。
谢谢！
编辑：与美国joinsfdisk输出：
[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 更新：
这个实例的重启彻底解决了性能问题。 托pipe服务提供商进一步的分析表明，有一些错位，但他们认为这不会导致经历的症状。 他们举例说，Windows虚拟机中的错位较大。 在这一点上，我们将等待，看看它是否再次发生，如果是这样，改变扇区偏移量。
查看alignment问题的唯一方法是测量主引导logging。 如果你可以从你的虚拟机做到这一点，你可以看到你是否错位。
也就是说，alignment问题会扩大您对存储器执行的IO数量，但是必须要有一些限制来防止您增加IO数量。 Netapp受此影响特别严重，因为一旦需要额外关注的“部分写入”数量达到一定水平，它们就开始限制性能。 其他系统只是对待每一个IO的方式与最后一个相同，所以不要有Netapp获得的存储延迟的巨大峰值。
你应该能够在Linux上find与sfdisk的对应关系。 只要看看你的分区的开始部分。 但是 ，这只会告诉你一半的故事，因为你的提供者可以/应该考虑存储层的默认操作系统alignment。
所以，即使看起来像63个扇区的错位，存储可能会有一个偏移到LUN或数据存储，以纠正它alignment的边界。 但至less你可以把你的新知识提供给你的提供者，让他们确认。
更新（对于新的sfdisk结果）：你的分区没有在同一个4KB或8KB的块边界上alignment，所以很可能你正在经历一些错位的痛苦。 您需要询问您的提供者存储器使用的块alignment方式（例如4KB）以及它们使用的alignment方式是否正确（如果有的话）。 如果它们没有任何alignment修正，你希望所有的分区都以扇区数开始，扇区数可以被8或16整除。当你在这个时候，一个1MB的开始偏移量（可以被2048整除）允许任何基础存储块大小在未来的变化。