Фря, gmirror. round-robin load prefer?

Rimlyanin · 20.11.2011

Фря, gmirror. round-robin load prefer?

помошь нужна от гуру...

Имеется FreeBSD

Код:

root@colo[Sun 21:25]/>uname -a
FreeBSD colo.colo 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Sat May 21 01:09:22 EEST 2011     @colo.colo:/usr/obj/usr/src/sys/COLO1  amd64

В нем 2*2Тб HDD

Код:

root@colo[Sun 21:26]/usr>atacontrol list
ATA channel 2:
    Master:      no device present
    Slave:       no device present
ATA channel 3:
    Master:      no device present
    Slave:       no device present
ATA channel 4:
    Master:      no device present
    Slave:       no device present
ATA channel 5:
    Master: ad10 <ST2000DL003-9VT166/CC32> SATA revision 2.x
    Slave:       no device present
ATA channel 6:
    Master: ad12 <WDC WD20EARS-00MVWB0/51.0AB51> SATA revision 2.x
    Slave:       no device present

собранные в зеркало

Код:

root@colo[Sun 21:27]/usr>gmirror list
Geom name: gm0
State: COMPLETE
Components: 2
Balance: round-robin
Slice: 4096
Flags: NONE
GenID: 1
SyncID: 13
ID: 376546712
Providers:
1. Name: mirror/gm0
   Mediasize: 2000398933504 (1.8T)
   Sectorsize: 512
   Mode: r3w3e8
Consumers:
1. Name: ad10
   Mediasize: 2000398934016 (1.8T)
   Sectorsize: 512
   Mode: r1w1e1
   State: ACTIVE
   Priority: 0
   Flags: NONE
   GenID: 1
   SyncID: 13
   ID: 2545080381
2. Name: ad12
   Mediasize: 2000398934016 (1.8T)
   Sectorsize: 512
   Mode: r1w1e1
   State: ACTIVE
   Priority: 0
   Flags: NONE
   GenID: 1
   SyncID: 13
   ID: 1559642208

основное место отдано под файлохранилище

Код:

root@colo[Sun 21:27]/usr>mount
/dev/mirror/gm0s1a on / (ufs, local)
devfs on /dev (devfs, local, multilabel)
/dev/mirror/gm0s1d on /SAMBA (ufs, local, soft-updates)
devfs on /var/named/dev (devfs, local, multilabel)

Если нужна ещё какая то инфа - легко.

Так вот, суть проблемы в том, что если удалить на /SAMBA ну к примеру 100-200 гиг инфы (достаточно крупные файлы, рар-архивы с ограничением на размер одного блока в 1 гиг) то сервак некоторое, довольно продолжительное время откливается очень медленно.
В

Код:

top -m io -o total

все нормально, но по

Код:

gsat

нагрузка на один из винтов порядка 100%

Что делать ? куда копать ?

Rimlyanin · 20.11.2011

screen,
в одном окне

Код:

dd if=/dev/random of=/SAMBA/test/test1 bs=1M count=1024

в другом gstat

Код:

dT: 1.011s  w: 1.000s
 
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
 
    0    176      1     16   37.0    175  22273    2.2   18.6| ad10
 
    8    167      0      0    0.0    167  21261   25.3   65.8| ad12
 
    8    168      1     16   37.0    167  21261   25.5   70.5|mirror/gm0
 
    8    168      1     16   37.0    167  21261   25.6   70.6|mirror/gm0s1
 
    0      0      0      0    0.0      0      0    0.0    0.0|mirror/gm0s1a
 
    0      0      0      0    0.0      0      0    0.0    0.0|mirror/gm0s1b
 
    8    168      1     16   37.0    167  21261   25.8   71.2|mirror/gm0s1d

================================

Код:

dd if=/dev/random of=/SAMBA/test/test2 bs=4K count=262144
262144+0 records in
262144+0 records out
1073741824 bytes transferred in 49.847935 secs (21540347 bytes/sec)

Код:

dT: 1.026s  w: 1.000s
 
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
 
    1     23      0      0    0.0     23   2995    6.8    6.8| ad10
 
    8     24      0      0    0.0     24   3119  262.9  102.1| ad12
 
    8     24      0      0    0.0     24   3119  262.9  102.1|mirror/gm0
 
    8     24      0      0    0.0     24   3119  262.9  102.1|mirror/gm0s1
 
    1      0      0      0    0.0      0      0    0.0    0.0|mirror/gm0s1a
 
    0      0      0      0    0.0      0      0    0.0    0.0|mirror/gm0s1b
 
    7     24      0      0    0.0     24   3119  262.9  102.1|mirror/gm0s1d

=================================

Код:

dd if=/dev/random of=/SAMBA/test/test2 bs=512count=2097152
2097152+0 records in
2097152+0 records out
1073741824 bytes transferred in 47.114229 secs (22790181 bytes/sec)

Код:

dT: 1.005s  w: 1.000s
 
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
 
    0    179      0      0    0.0    179  22932    0.7   12.8| ad10
 
    1    184      0      0    0.0    184  23569   18.6   72.2| ad12
 
    1    184      0      0    0.0    184  23569   18.8   73.9|mirror/gm0
 
    1    184      0      0    0.0    184  23569   18.8   74.0|mirror/gm0s1
 
    0      0      0      0    0.0      0      0    0.0    0.0|mirror/gm0s1a
 
    0      0      0      0    0.0      0      0    0.0    0.0|mirror/gm0s1b
 
    1    184      0      0    0.0    184  23569   18.8   74.1|mirror/gm0s1d

49 и 47 секунд - разница не большая

Но, Если ДД из рандома на винт пишет один гиг за 49 секунд, то запись 100 гиг занимает 4900 секунд, иди один час 21ну минуту и 40 секунд.
что очень похоже по срокам медленного отклика от сервера...
Такое ощущение что оно не просто удаляет файл, а затирает его...

CRASHUS · 29.11.2011

навскидку

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.

Rimlyanin · 02.12.2011

BirdGovorun · 14.02.2012

Из-за синхронизации тормозит, ничего не поделаешь,
у меня зеркало развалилось, так синхронизация с новым диском
на 250Gb, примерно 40 минут тормозов.
И в добавок, Фря не любит "зелёные" диски, намучался с ними.
Ещё памяти у вас сколько, в swap система лезет?
Если в swap полезла, ещё один хороший тормоз.
На ZFS переходите.

Rimlyanin · 15.02.2012

BirdGovorun сказав(ла):
Из-за синхронизации тормозит, ничего не поделаешь,
у меня зеркало развалилось, так синхронизация с новым диском
на 250Gb, примерно 40 минут тормозов.
И в добавок, Фря не любит "зелёные" диски, намучался с ними.
Ещё памяти у вас сколько, в swap система лезет?
Если в swap полезла, ещё один хороший тормоз.
На ZFS переходите.

ты не путай, после развала зеркала ему нужен ребилд...
Или ты хо сказать что он ребилд делат каждый раз при каком то изменении файловой системы?

В свап не лезет

Код:

last pid:  7141;  load averages:  0.19,  0.26,  0.20                        up 1+01:26:37  00:35:06
88 processes:  1 running, 87 sleeping
CPU:  2.6% user,  0.0% nice,  2.6% system,  4.5% interrupt, 90.2% idle
Mem: 77M Active, 657M Inact, 192M Wired, 25M Cache, 110M Buf, 18M Free
Swap: 2048M Total, 296K Used, 2048M Free

BirdGovorun · 15.02.2012

Rimlyanin сказав(ла):
Или ты хо сказать что он ребилд делат каждый раз при каком то изменении файловой системы?

Именно это и хочу сказать.

Rimlyanin сказав(ла):
В свап не лезет

Код:

last pid: 7141; load averages: 0.19, 0.26, 0.20 up 1+01:26:37 00:35:06 88 processes: 1 running, 87 sleeping CPU: 2.6% user, 0.0% nice, 2.6% system, 4.5% interrupt, 90.2% idle Mem: 77M Active, 657M Inact, 192M Wired, 25M Cache, 110M Buf, 18M Free Swap: 2048M Total, 296K Used, 2048M Free

В момент удаления надо посмотреть swap.
Если в момент удаления лезет в swap, а он на диске, а диск в этот
момент загружен, сами понимаете.
Ещё раз повторю и тебя "зелёные" диски, во FreeBSD они себя ведут как-то странно,
могут тормозить сами по себе, да что-там, они и в Windows чудеса вытворяют.

Rimlyanin · 16.02.2012

BirdGovorun сказав(ла):
Именно это и хочу сказать.

В момент удаления надо посмотреть swap.
Если в момент удаления лезет в swap, а он на диске, а диск в этот
момент загружен, сами понимаете.
Ещё раз повторю и тебя "зелёные" диски, во FreeBSD они себя ведут как-то странно,
могут тормозить сами по себе, да что-там, они и в Windows чудеса вытворяют.

с какой стати ему лезть в свап?

P.S. не лезет

ASDev · 16.02.2012

У клиента был случай, он в НАС в рейд засунул грины. Так у него рейд постоянно отваливался, т.к. не приходил отклик от винта за требуемое время

BirdGovorun · 17.02.2012

Вот ещё один из вариантов увеличить отзывчивость системы.
Посмотреть какой планировщик:
#sysctl -a | grep kern.sched.name
По умолчанию используется ULE и если одно или двух ядерный процессор
то лучше перейти на 4BSD.
Можно здесь посмотреть->

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.

результаты, есть ещё FBFS планировщик, но с ним как-то неоднозначно,
да и экспериментальный он.

Rimlyanin · 21.02.2012

ASDev сказав(ла):
У клиента был случай, он в НАС в рейд засунул грины. Так у него рейд постоянно отваливался, т.к. не приходил отклик от винта за требуемое время

мало данных.
Что за нас, что за контроллер в нем, какие у него установки, и т.д.

в таком

⚠ Тільки зареєстровані користувачі бачать весь контент та не бачать рекламу.

WD тоже ставит пару зеленых дисков, и никто не разваливается

несколько десятков таких расставил в качестве бакапохранилищ, в конгурации дисков RAID1
Проблема была только с одним: его стукнули

ASDev · 21.02.2012

Точно помню что был Синолоджи, по модели уже не вспомню... Нормально заработал только с Е серией сигейта

Rimlyanin · 21.02.2012

ASDev сказав(ла):
Точно помню что был Синолоджи, по модели уже не вспомню... Нормально заработал только с Е серией сигейта

ну хз, хз, синолоджи мне по цене не нравятся, там где два и более HDD - проще комп на атоме собрать.

BirdGovorun · 28.02.2012

С появлением новых жёстких дисков, имеющих размер кластера 4кБ необходимо следить, чтобы начальный и конечный сектора (блоки) были выравнены по 4кБ. При этом не стоит забывать, что для внешних (относительно жёсткого диска) систем контроллер последнего эмулирует размер сектора всё таким же 512 байтным. В случае не выравненности разделов возникает проблема сильного снижения скорости передачи данных с активным использованием жёсткого диска в процессе работы.
В связи с использованием в новых моделях жестких дисков Western Digital Caviar Green нестандартного размера сектора, увеличенного с 512 байт до 4 Кб, предпринята попытка оценки степени поддержки таких дисков в Linux. В итоге были получены удручающие результаты: из-за отсутствия выравнивания записываемого кластера данных по границе физического сектора размером 4096 байт (выравнивание производится по 512-байтовым логическим секторам), наблюдается падение производительности более чем в три раза. Проблема возникает из-за того, что при разбивке диска некорректно вычисляется оптимальное смещение для первичного дискового раздела, который по умолчанию создается начиная с позиции LBA 63, оставаясь не выравненным по границе цилиндров.

Размер секторов на диске у вас какой?

Rimlyanin · 01.03.2012

BirdGovorun сказав(ла):
Размер секторов на диске у вас какой?

выровняный...

ChuguevMan · 01.03.2012

Rimlyanin, так себя Фряшечка и gmirror не ведут в нормальных условиях.
Ставь smartmontools, bonnie++
Тестируй.
Тем более ты говоришь 1 Гиг нормально прокачивается, а 100 медленно.
Тут или поверхность или одно из двух.

Rimlyanin · 01.03.2012

ChuguevMan сказав(ла):
Rimlyanin, так себя Фряшечка и gmirror не ведут в нормальных условиях.
Ставь smartmontools, bonnie++
Тестируй.
Тем более ты говоришь 1 Гиг нормально прокачивается, а 100 медленно.
Тут или поверхность или одно из двух.

smartmontools ? что тебе из смарта показать?

ChuguevMan · 04.03.2012

Прогноз погоды. Ведь именного его показывает smartmontools?

Намедни делал зеркало в Линупсе через mdadm. Два 2-х терабайтных винта. Уже после начала синхронизации создал файловую систему и примонтировал ее. После обнаружил странно страшно медленную скорость синхронизации - порядка 2-3 Мбайт/с.
Отмонтировал - резко увеличилось до 140 Мбайт/с. И это при том что я ничего не писал и не читал на ФС. Лялик, он такой.

Rimlyanin · 05.03.2012

ChuguevMan сказав(ла):
Прогноз погоды. Ведь именного его показывает smartmontools?

Намедни делал зеркало в Линупсе через mdadm. Два 2-х терабайтных винта. Уже после начала синхронизации создал файловую систему и примонтировал ее. После обнаружил странно страшно медленную скорость синхронизации - порядка 2-3 Мбайт/с.
Отмонтировал - резко увеличилось до 140 Мбайт/с. И это при том что я ничего не писал и не читал на ФС. Лялик, он такой.

Код:

/usr/local/sbin/smartctl -A

Подойдет?

BirdGovorun · 07.03.2012

Всё нормально у вас на таких дисках

Берём калькулятор и считаем:
100 Гектар со скоростью

1073741824 bytes transferred in 49.847935 secs (21540347 bytes/sec)

22 мегабайта/сек

100 000 мб/22 мб/с = 4545.45 секунд
результат приблизительно ваш.
У вас "зеленые" диски и имеют 5900 оборотов, скрость запись/чтение
меньше чем у 7500 оборотистых
Вот мой Сигейт 160G SATA 7500 об

diskinfo -t ada0
ada0
512 # sectorsize
160041885696 # mediasize in bytes (149G)
312581808 # mediasize in sectors
0 # stripesize
0 # stripeoffset
310101 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
6PT0L19L # Disk ident.

Seek times:
Full stroke: 250 iter in 7.061492 sec = 28.246 msec
Half stroke: 250 iter in 4.952781 sec = 19.811 msec
Quarter stroke: 500 iter in 7.872871 sec = 15.746 msec
Short forward: 400 iter in 2.369139 sec = 5.923 msec
Short backward: 400 iter in 3.260776 sec = 8.152 msec
Seq outer: 2048 iter in 0.184565 sec = 0.090 msec
Seq inner: 2048 iter in 0.202917 sec = 0.099 msec
Transfer rates:
outside: 102400 kbytes in 1.450310 sec = 70606 kbytes/sec
middle: 102400 kbytes in 1.661696 sec = 61624 kbytes/sec
inside: 102400 kbytes in 2.971847 sec = 34457 kbytes/sec

Вот на серваке с зеркалом два Сигейта по 120G

Transfer rates:
outside: 102400 kbytes in 1.720537 sec = 59516 kbytes/sec
middle: 102400 kbytes in 2.003895 sec = 51100 kbytes/sec
inside: 102400 kbytes in 3.237310 sec = 31631 kbytes/sec

Посмотрите у себя.