У нас есть резервный сервер с 66 ТБ свободного места, настроенный так:
12 массивов RAID10 по 6 ТБ -> 12 PV -> 1 VG -> 1 LV -> xfs
Эта файловая система используется исключительно для резервного копирования (через BackupPC). Он получает довольно много операций ввода-вывода, но определенно не настолько, чтобы у оборудования возникли проблемы с этим. Однако мы сталкиваемся с множеством неудачных операций резервного копирования, и недавно я заметил, что даже запись одного 10-строчного файла при монтировании занимает> 20 секунд. Запуск iostat показывает, почему:
[root@lolno BackupPC]# iostat
Linux 2.6.18-194.17.1.el5 (lolno) 06/27/2012
avg-cpu: %user %nice %system %iowait %steal %idle
19.93 0.00 9.53 31.95 0.00 38.59
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 5.34 115.29 43.07 874600222 326773590
sda1 0.00 0.00 0.00 3586 126
sda2 5.34 115.29 43.07 874594516 326773464
sdb 207.33 3544.02 1594.70 26886233184 12097955904
sdc 11.39 844.42 1033.16 6406058328 7837945704
sdd 11.20 622.92 481.77 4725691832 3654875728
sde 15.84 1812.99 1661.13 13754015304 12601927592
sdf 14.86 1483.24 888.80 11252361120 6742733600
sdg 11.67 1020.94 746.05 7745220408 5659828008
sdh 22.60 1127.12 1424.24 8550776952 10804834600
sdi 12.66 1176.71 1043.97 8926929272 7919898000
sdj 13.50 1140.80 912.27 8654489384 6920787296
sdk 13.14 1314.36 1041.48 9971220872 7901060992
sdl 11.16 674.53 366.49 5117257008 2780306920
sdm 10.82 829.36 604.99 6291851320 4589685592
dm-0 2.82 24.81 9.80 188208594 74373432
dm-1 0.00 0.00 0.00 680 0
dm-2 2.52 50.08 5.81 379928338 44067760
dm-3 8.48 40.40 27.46 306454472 208332272
dm-4 364.33 15591.41 11799.05 118282051176 89511839936
Как вы можете видеть, вместо того, чтобы ввод-вывод равномерно распределялся между дисками / PV, подавляющее большинство его было сосредоточено на одном диске. Что могло бы вызвать это?
Еще немного информации о системе:
Он работает под управлением CentOS 5.5 с ядром 2.6.18-194.17.1.el5
[root@lolno BackupPC]# xfs_info /data
meta-data=/dev/mapper/backup_vg1-BackupLV isize=256 agcount=66, agsize=268435455 blks
= sectsz=4096 attr=0
data = bsize=4096 blocks=17581608960, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal bsize=4096 blocks=32768, version=2
= sectsz=4096 sunit=1 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
[root@lolno BackupPC]# lvdisplay -v /dev/backup_vg1/BackupLV
Using logical volume(s) on command line
--- Logical volume ---
LV Name /dev/backup_vg1/BackupLV
VG Name backup_vg1
LV UUID L8i09U-lVxh-1ETM-mNRQ-j3es-uCSI-M1xz45
LV Write Access read/write
LV Status available
# open 1
LV Size 65.50 TB
Current LE 17169540
Segments 12
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:4
Моя первая мысль заключалась в том, что это как-то связано с отсутствием чередования в xfs, но согласно http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/xfsmain.html#xfscreating
«При создании файловых систем на томах lvm или md mkfs.xfs выбирает оптимальную геометрию».
Так это просто здесь не происходит или происходит что-то еще?
Из agcount=66 вы можете видеть, что у вас есть 66 групп распределения (т.е. 66 потенциальных потоков ввода-вывода), но только 12 физических блочных устройств.
XFS будет пытаться чтобы поместить каждый новый каталог в другой AG, поэтому, если вы выполняете много операций ввода-вывода в одном каталоге, вы можете выполнять однопоточный ввод-вывод для одного AG, который хранится на одном блочном устройстве.
Также возможно, что даже если вы выполняете ввод-вывод для разных групп AG, несколько из этих 66 AG находятся на одном блочном устройстве. 66/12 = 5.5, поэтому у вас может быть до 5 потоков ввода-вывода, записывающих данные для 5 AG на одно базовое блочное устройство.
Из sunit=0 swidth=0 вы можете видеть, что файловая система вообще не знает о базовом массиве RAID.
Я думаю, ваша файловая система сделана неправильно. mkfs.xfs не так уж и умно.
Прочтите документацию XFS, узнайте, как структурирована файловая система и как ваши существующие данные могут в конечном итоге распределиться по этим структурам. Это удивительно простая для понимания файловая система.
У вас здесь хорошее положение, потому что у вас действительно есть данные, на которые нужно смотреть, а вы не работаете с какой-то воображаемой спецификацией от разработчиков приложения, которая со временем будет меняться.
Измените файловую систему, чтобы она лучше соответствовала вашим данным, блочным устройствам и структуре RAID. В частности «Как рассчитать правильные значения sunit, swidth для оптимальной производительности» Вопрос в FAQ будет вам полезен, но это не единственное, на что стоит обратить внимание: