Определение количества эффектов неточного совмещения раздела
Я испытываю некоторые значительные проблемы производительности о сервере NFS. Я читал немного на выравнивании раздела, и я думаю, что мне неправильно выровняли мои разделы. Я не могу найти ничего, что говорит мне, как на самом деле определить количество эффектов неправильно выровненных разделов. Часть общей информации, которую я нашел, предполагает, что потеря производительности может быть довольно высокой (вверх 60%), и другие говорят, что это незначительно. То, что я хочу сделать, определяют, является ли выравнивание раздела фактором в проблемах с производительностью этого сервера или нет; и если так, до какой степени?
Таким образом, я помещу свою информацию здесь, и надо надеяться сообщество может подтвердить, неправильно выравниваются ли мои разделы действительно, и если так, помогают мне поместить число в то, какова стоимость производительности.
Сервером является Dell R510 с двойными центральными процессорами E5620 и 8 ГБ RAM. Существует восемь 15k 2.5” диски на 600 ГБ (Seagate ST3600057SS), настроенный в аппаратных средствах RAID-6 с единственным горячим резервированием. RAID-контроллером является PERC H700 Dell w/512MB кэш (Linux рассматривает это как LSI MegaSAS 9260). ОС является CentOS 5.6, раздел корневого каталога является ext3, с опциями “rw, data=journal, usrquota”.
У меня есть RAID HW, настроенный для представления двух виртуальных дисков ОС:/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]
Размер блока совпадает с размером полосы, правильно? Если так, затем 64 КБ:
# /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 (экспортируемое дерево корневого каталога).
Ваши разделы неправильно выровнены, и может быть трудно оценить, сколько вы фактически теряете в производительности, потому что это будет зависеть от типа нагрузки ввода-вывода. Это может быть незначительным, если ваша рабочая нагрузка ввода-вывода невелика по сравнению с производительностью ваших дисков. Однако, поскольку это сервер NFS, я предполагаю, что он не является незначительным и требует решения. По некоторым оценкам снижение производительности составляет 20-30%.
Несовпадение разделов в основном означает, что вам могут потребоваться две операции ввода-вывода на аппаратном уровне, чтобы выполнить одну операцию ввода-вывода на программном уровне. Если ваши программные блоки не заканчиваются на одной аппаратной границе, это произойдет. Из того, что вы написали, вы уже изучили и поняли это.
- Диск = 512-байтовые сектора
- RAID = 65536-байтовые полосы (OK)
- Раздел 0 = начиная с сектора 63 (смещение 32256 байтов )
- Раздел 1 = начало сектора 465885 (смещение 238533120 байт)
- Размер блока EXT2 / 3/4 =?
- Размер шага EXT2 / 3/4 =? ( калькулятор )
Помните, что несовпадение разделов отличается от того, когда ваша подсистема хранения использует размеры блоков, которые отличаются от того, что используется в вашем программном обеспечении. Это также может увеличить нагрузку на ваши диски, но на самом деле не связано с проблемами выравнивания.
Используйте tunefs -l / dev / sdaX | grep size , чтобы проверить размер блока в вашей файловой системе.
Согласно рекомендациям Red Hat Enterprise Linux:
Как правило, рекомендуется выровнять разделы по размеру, кратному одному МБ (1024x1024 байта). Для достижения выравнивания начальные секторы разделов всегда должны быть кратны 2048, а конечные секторы всегда должны быть кратны 2048 минус 1. Обратите внимание, что первый раздел не может начинаться в секторе 0, вместо этого используйте сектор 2048.
Похоже, вам нужно переместить данные и воссоздать разделы, если это действительно основная причина проблемы с производительностью NFS. Однако все это обычно более сложно, и я бы попытался найти доказательства того, что все в порядке, прежде чем рассматривать дорогостоящую переустановку.