我在 NFS 服务器上遇到了一些严重的性能问题。我一直在阅读有关分区对齐的资料，并且思考我的分区没有对齐。我找不到任何可以告诉我如何量化分区未对齐的影响。我发现的一些一般信息表明性能损失可能相当高（高达 60%），而其他人则说可以忽略不计。我想要做的是确定分区对齐是否是此服务器性能问题的一个因素；如果是，那么影响程度如何？
因此我将在这里发布我的信息，希望社区能够确认我的分区是否确实未对齐，如果是，请帮我计算一下性能成本。
服务器是 Dell R510，配备双 E5620 CPU 和 8 GB RAM。有八个 15k 2.5 英寸 600 GB 驱动器（Seagate ST3600057SS），配置为硬件 RAID-6，带有一个热备用。RAID 控制器是 Dell PERC H700，带 512MB 缓存（Linux 将其视为 LSI MegaSAS 9260）。操作系统是 CentOS 5.6，主目录分区是 ext3，选项为“rw,data=journal,usrquota”。
我已将 HW RAID 配置为向操作系统显示两个虚拟磁盘：/dev/sda 用于操作系统（启动、根和交换分区），/dev/sdb 用于大型 NFS 共享：
[root@lnxutil1 ~]# parted -s /dev/sda unit s print
Model: DELL PERC H700 (scsi)
Disk /dev/sda: 134217599s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 63s 465884s 465822s primary ext2 boot
2 465885s 134207009s 133741125s primary lvm
[root@lnxutil1 ~]# parted -s /dev/sdb unit s print
Model: DELL PERC H700 (scsi)
Disk /dev/sdb: 5720768639s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 34s 5720768606s 5720768573s lvm
编辑1 使用 cfq IO 调度程序（CentOS 5.6 的默认设置）：
# cat /sys/block/sd{a,b}/queue/scheduler
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
块大小与条带大小相同，对吗？如果是这样，那么64kB：
# /opt/MegaCli -LDInfo -Lall -aALL -NoLog
Adapter #0
Number of Virtual Disks: 2
Virtual Disk: 0 (target id: 0)
Name:os
RAID Level: Primary-6, Secondary-0, RAID Level Qualifier-3
Size:65535MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:7
Span Depth:1
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk's Default
Number of Spans: 1
Span: 0 - Number of PDs: 7
... physical disk info removed for brevity ...
Virtual Disk: 1 (target id: 1)
Name:share
RAID Level: Primary-6, Secondary-0, RAID Level Qualifier-3
Size:2793344MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:7
Span Depth:1
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk's Default
Number of Spans: 1
Span: 0 - Number of PDs: 7
如果不明显的话，对于操作系统来说，虚拟磁盘 0 对应于 /dev/sda；虚拟磁盘 1 是 /dev/sdb（导出的主目录树）。
答案1
您的分区未对齐，可能很难评估您实际损失的性能，因为这取决于 I/O 工作负载的类型。如果您的 I/O 工作负载与磁盘性能相比很轻，那么它可能可以忽略不计。但是，由于这是 NFS 服务器，我假设它不可忽略，应该予以解决。一些估计将性能损失控制在 20-30%。
分区错位基本上意味着您可能需要两个硬件级别的 I/O 操作才能满足一个软件级别的 I/O 操作。如果您的软件块不是以相同的硬件边界结束，就会发生这种情况。从您所写的内容来看，您已经研究并理解了这一点。
- 磁盘 = 512 字节扇区
- RAID = 65536 字节条带（正常）
- 分区 0 = 从扇区 63 开始（32256 字节偏移量）
- 分区 1 = 从扇区 465885 开始（238533120 字节偏移量）
- EXT2/3/4 块大小 = ？
- EXT2/3/4 步幅大小 = ？（计算器）
请记住，分区错位不同于存储子系统使用与软件不同的块大小。这也会给磁盘带来更多压力，但与对齐问题无关。
用于tunefs -l /dev/sdaX | grep size检查文件系统上的块大小。
根据 Red Hat Enterprise Linux 的建议：
通常，将分区对齐为 1 MB（1024x1024 字节）的倍数是个好主意。为了实现对齐，分区的起始扇区应始终为 2048 的倍数，而结束扇区应始终为 2048 的倍数减 1。请注意，第一个分区不能从扇区 0 开始，而是使用扇区 2048。
如果这确实是 NFS 性能问题的根本原因，那么您可能不得不移动数据并重新创建分区。但是，整个过程通常更复杂，在考虑昂贵的重新安装之前，我会尝试找到其他事情正常的证据。