У меня возникли серьезные проблемы с производительностью на сервере NFS. Я немного читал о выравнивании разделов, и я считать Мои разделы неправильно выровнены. Я не могу найти ничего, что подсказывало бы мне, как на самом деле количественно оценить последствия неправильного выравнивания перегородок. Часть общей информации, которую я обнаружил, предполагает, что снижение производительности может быть довольно высоким (более 60%), а другие говорят, что оно незначительно. Что я хочу сделать, так это определить, является ли выравнивание разделов фактором проблем с производительностью этого сервера или нет; и если да, то в какой степени?
Поэтому я размещу здесь свою информацию и, надеюсь, сообщество сможет подтвердить, действительно ли мои разделы выровнены неправильно, и если да, помогите мне указать число, какова стоимость производительности.
Сервер - это Dell R510 с двумя процессорами E5620 и 8 ГБ оперативной памяти. Имеется восемь жестких дисков 15k 2,5 ”600 ГБ (Seagate ST3600057SS), сконфигурированных в виде аппаратного RAID-6 с одним« горячим »резервом. RAID-контроллер - это Dell PERC H700 с кеш-памятью 512 МБ (Linux видит это как LSI MegaSAS 9260). ОС - CentOS 5.6, раздел домашнего каталога - ext3, с параметрами «rw, data = journal, usrquota».
У меня HW RAID настроен для представления двух виртуальных дисков в ОС: / dev / sda для ОС (загрузочный, корневой и swap-разделы) и / 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 (по умолчанию для 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%.
Несовпадение разделов в основном означает, что вам могут потребоваться две операции ввода-вывода на аппаратном уровне, чтобы выполнить одну операцию ввода-вывода на программном уровне. Если ваши программные блоки не заканчиваются на одной аппаратной границе, это произойдет. Из того, что вы написали, вы уже исследовали и понимаете это.
Имейте в виду, что несовпадение разделов отличается от того, когда ваша подсистема хранения использует размеры блоков, которые отличаются от того, что использует ваше программное обеспечение. Это также может увеличить нагрузку на ваши диски, но на самом деле не связано с проблемами выравнивания.
Использовать tunefs -l /dev/sdaX | grep size чтобы проверить размер блока в вашей файловой системе.
Согласно рекомендациям Red Hat Enterprise Linux:
Как правило, рекомендуется выровнять разделы по размеру, кратному одному МБ (1024x1024 байта). Чтобы добиться выравнивания, начальные секторы разделов всегда должны быть кратны 2048, а конечные секторы всегда должны быть кратны 2048 минус 1. Обратите внимание, что первый раздел не может начинаться с сектора 0, используйте вместо этого сектор 2048.
Похоже, вам может понадобиться переместить данные и воссоздать разделы, если это действительно основная причина проблемы с производительностью NFS. Однако все это обычно более сложно, и я бы попытался найти доказательства того, что все в порядке, прежде чем рассматривать дорогостоящую переустановку.