Количественная оценка последствий неправильного выравнивания раздела

У меня возникли серьезные проблемы с производительностью на сервере NFS. Я немного читал о выравнивании разделов, и я думаю, что мои разделы неправильно выровнены. Я не могу найти ничего, что подсказывало бы мне, как на самом деле количественно оценить эффекты неправильно выровненных разделов. Некоторые из общей информации, которую я нашел, предполагают, что снижение производительности может быть довольно высоким (более 60%), а другие говорят, что оно незначительно. Что я хочу сделать, это определить, является ли выравнивание разделов фактором в проблемах производительности этого сервера или нет; и если да, то в какой степени?

Поэтому я выложу здесь свою информацию, и, надеюсь, сообщество сможет подтвердить, действительно ли мои разделы выровнены неправильно, и если да, то помогите мне определить, сколько стоит производительность.

Сервер Dell R510 с двумя процессорами E5620 и 8 ГБ оперативной памяти. В аппаратном RAID-6 есть восемь жестких дисков объемом 15 КБ по 2,5 ГБ (Seagate ST3600057SS) с одним горячим резервом. RAID-контроллер представляет собой Dell PERC H700 с 512 МБ кэш-памяти (Linux рассматривает это как LSI MegaSAS 9260). ОС - CentOS 5.6, раздел домашнего каталога - ext3, с опциями "rw,data=journal,usrquota".

У меня есть HW RAID, сконфигурированный для представления двух виртуальных дисков в ОС: /dev/sda для ОС (разделы boot, root и 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 (экспортированное дерево домашних каталогов).

Источник

1 ответ

Решение

Ваши разделы выровнены неправильно, и может быть трудно оценить, сколько вы на самом деле теряете в производительности, потому что это будет зависеть от типа рабочей нагрузки ввода-вывода. Это может быть незначительным, если ваша рабочая нагрузка ввода-вывода невелика по сравнению с производительностью ваших дисков. Однако, поскольку это NFS-сервер, я предполагаю, что он не является ничтожным и должен быть решен. По некоторым оценкам, снижение производительности составляет 20-30%.

Смещение разделов в основном означает, что вам может потребоваться две операции ввода-вывода на аппаратном уровне, чтобы удовлетворить одну операцию ввода-вывода на программном уровне. Если ваши программные блоки не заканчиваются на той же аппаратной границе, это произойдет. Из того, что вы написали, вы уже исследовали и поняли это.

  • Диск = 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:

Как правило, рекомендуется выровнять разделы по кратному одному МБ (1024x1024 байта). Для достижения выравнивания начальные сектора разделов всегда должны быть кратны 2048, а конечные сектора всегда должны быть кратны 2048 минус 1. Обратите внимание, что первый раздел не может начинаться с сектора 0, вместо этого используйте сектор 2048.

Похоже, что вам может понадобиться переместить данные и воссоздать разделы, если это действительно является основной причиной проблемы производительности NFS. Тем не менее, все это обычно более сложно, и я бы попытался найти доказательства того, что с другими вещами все в порядке, прежде чем рассматривать дорогостоящую переустановку.

Источник
Другие вопросы по тегам