Низкая скорость работы диска DS4800


Главная Форумы Storage SAN, Disk & Tape Низкая скорость работы диска DS4800

В этой теме 12 ответов, 5 участников, последнее обновление  uxTuaHgp 6 года/лет, 9 мес. назад.

  • Автор
    Сообщения
  • #11527

    Viper
    Участник

    Добрый день.

    На AIX собран LV страйпом на двух дисках

    [spoiler]bash-3.00# lslv fileslv
    LOGICAL VOLUME: fileslv VOLUME GROUP: vgedb
    LV IDENTIFIER: 00c5919200004c000000012e496b092c.2 PERMISSION: read/write
    VG STATE: active/complete LV STATE: opened/syncd
    TYPE: jfs2 WRITE VERIFY: off
    MAX LPs: 1470 PP SIZE: 256 megabyte(s)
    COPIES: 1 SCHED POLICY: striped
    LPs: 1470 PPs: 1470
    STALE PPs: 0 BB POLICY: relocatable
    INTER-POLICY: maximum RELOCATABLE: no
    INTRA-POLICY: middle UPPER BOUND: 2
    MOUNT POINT: /files LABEL: /files
    MIRROR WRITE CONSISTENCY: on/ACTIVE
    EACH LP COPY ON A SEPARATE PV ?: yes (superstrict)
    Serialize IO ?: NO
    STRIPE WIDTH: 2
    STRIPE SIZE: 128k
    DEVICESUBTYPE : DS_LVZ
    [/spoiler]

    [spoiler]bash-3.00# lslv -m fileslv | more
    fileslv:/ftas01/prod/oebs/db/apps_st/data/files
    LP PP1 PV1 PP2 PV2 PP3 PV3
    0001 0215 hdisk4
    0002 0215 hdisk5
    0003 0216 hdisk4
    0004 0216 hdisk5
    0005 0217 hdisk4
    0006 0217 hdisk5

    —cut—-
    [/spoiler]

    При этом topas показывает удручающие цифры
    [code]
    Disk Busy% KBPS TPS KB-Read KB-Writ
    hdisk4 97.0 988.0 247.0 30.0 658.0
    dac0 0.0 988.0 247.0 30.0 658.0
    dac1 0.0 960.0 240.0 20.0 640.0
    hdisk5 2.0 960.0 240.0 20.0 640.0 [/code]

    Со стороны дискового массива (DS4800) оба диска — луны с двух разных raid10 из 12 шпинделей, сидящих на разных контроллерах.

    Всё собрано симметрично. Почему же hdisk5 пишет нормально, а hdisk4 при 1MB/s загружен на 100% ?

    Ниже вывод filemon
    [spoiler]————————————————————————
    Detailed Physical Volume Stats (512 byte blocks)
    ————————————————————————

    VOLUME: /dev/hdisk4 description: N/A
    reads: 12871 (0 errs)
    read sizes (blks): avg 8.0 min 8 max 8 sdev 0.0
    read times (msec): avg 0.085 min 0.067 max 0.300 sdev 0.006
    read sequences: 12871
    read seq. lengths: avg 8.0 min 8 max 8 sdev 0.0
    writes: 25738 (0 errs)
    write sizes (blks): avg 8.0 min 8 max 8 sdev 0.0
    write times (msec): avg 9.423 min 2.149 max 52.211 sdev 2.534
    write sequences: 12872
    write seq. lengths: avg 16.0 min 8 max 16 sdev 0.2
    seeks: 25743 (66.7%)
    seek dist (blks): init 118786752,
    avg 1520.0 min 8 max 6519848 sdev 99027.7
    seek dist (%tot blks):init 21.29396,
    avg 0.00027 min 0.00000 max 1.16876 sdev 0.01775
    time to next req(msec): avg 4.073 min 0.014 max 52.238 sdev 5.672
    throughput: 981.9 KB/sec
    utilization: 0.96

    VOLUME: /dev/hdisk5 description: N/A
    reads: 12864 (0 errs)
    read sizes (blks): avg 8.0 min 8 max 8 sdev 0.0
    read times (msec): avg 0.085 min 0.067 max 0.341 sdev 0.007
    read sequences: 12864
    read seq. lengths: avg 8.0 min 8 max 8 sdev 0.0
    writes: 25731 (0 errs)
    write sizes (blks): avg 8.0 min 8 max 8 sdev 0.0
    write times (msec): avg 0.211 min 0.173 max 8.542 sdev 0.108
    write sequences: 12871
    write seq. lengths: avg 16.0 min 8 max 16 sdev 0.2
    seeks: 25735 (66.7%)
    seek dist (blks): init 118786560,
    avg 1617.4 min 8 max 6942184 sdev 105392.3
    seek dist (%tot blks):init 21.29393,
    avg 0.00029 min 0.00000 max 1.24447 sdev 0.01889
    time to next req(msec): avg 4.066 min 0.014 max 427.211 sdev 37.813
    throughput: 981.6 KB/sec
    utilization: 0.03
    [/spoiler]

  • #11528

    uxTuaHgp
    Участник

    мониторили нагрузку на тома и контроллеры DS?
    Может быть тот контроллер обслуживает какой-нибудь том огромный в RAID5, который нагрузили записью?
    Диска вылетевшего совершенно случайно нет на DS? Если массив использует spare — выключается кэш на запись.

  • #11529

    Viper
    Участник

    Да, посмотрел.
    На тот момент кроме этих двух лунов на контроллерах другого IO не было вообще.
    Настройки кэша и страйп сайз везде одинаковый.
    Все диски в порядке. Про кэш написано что он включен, но сейчас standby (что это значит?)
    Но это для обоих лунов, почему такая адская ассиметрия получилась — непонятно.

    Даже не знаю, на что грешить.
    Оптика? san-свитч? Но что я могу там увидить кроме низкой фактической скорости?

  • #11530

    uxTuaHgp
    Участник

    На свичах можно посмотреть попытаться portshow portstatsshow
    на предмет количества ошибок
    Ну и switchshow до кучи — не прыгает ли скорость на порту, может быть ее нужно руками выставить, чтобы не скакало и ошибки не лезли или там патчкорд поменять.

    Параметры дисков одинаковые абсолютно?
    Никакие queue_depth не меняли?

  • #11531

    Viper
    Участник

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

  • #11533

    Ivan
    Участник

    multipath нативный или возможно sddpcm?
    Маппинг лунов выполняли в одно время или, допустим, был один лун, а через год решили еще один примапить?

  • #11535

    Viper
    Участник

    MP нативный, дополнительно ничего не ставилось.
    Кстати для меня не изученый вопрос, если подскажете хорошую всеобъемлющую документацию по MPIO SDD и всякое такое буду очень признателен.

    LUN’ы мапились одновременно.

  • #11541

    Ivan
    Участник

    Глядя на filemon разницы я особо не увидел.
    Думаю необходимо сгенерировать бОльшую нагрузку (чтобы видеть разницу), в файловой с-ме сделать dd if=/dev/zero of=./file_name count=100000 bs=512k
    в этом случае мы явно, якобы, должны увидеть, что один из дисков работает медленнее другого, покажите что будет происходить.
    Во время нагрузки смотрите очередь на эти диски, можно командой:
    iostat -DRl 1 100

    sdd — http://www-1.ibm.com/support/docview.wss?uid=ssg1S7000303&aid=1

  • #11694

    Сергей
    Участник

    А что подразумевает аикс, когда говорит что диск ~100% бизи?
    т.е. чего он при этом меряет?

  • #11701

    uxTuaHgp
    Участник

    Присоединяюсь.
    Вообще это не бизи, а time_activity % — сколько времени в процентах диск или лента занимались обслуживанием запросов на ввод/вывод.

    Вроде бы все ясно, однако наткнулся недавно на неприятность одну:
    дали нам погонять EMC CX480, так вот на одном из двух вроде бы совершенно одинаковых метадевайсов пауэрпазовских tm_act% все время под 100% даже когда активности практически нет.
    WIO при этом низкий.
    И на кларике все показатели в норме.

    Меня больше интересует, а не влияет-ли высокий tm_act% на поведение системы?

  • #11713

    Oleg
    Участник

    Про кэш написано что он включен, но сейчас standby (что это значит?)

    для DS4800 это означает, что отложенная запись ОТКЛЮЧЕНА (невзирая на настройки), так что ищите первопричину

  • #11715

    Oleg
    Участник

    Меня больше интересует, а не влияет-ли высокий tm_act% на поведение системы?

    нужно смотреть не на tm_act%, а на время отклика дисков (service time)
    если данный параметр находится в рамках рекомендованных значений,
    а для 1-tier (OLAP,OLTP,…) приложений — это порядка 5ms
    для 2-tier (MS Exch, IBM Domino) приложений — это порядка 20ms
    то вообщем то некритично какой там процент busy time…

  • #11724

    uxTuaHgp
    Участник

    Это ладно. Дело понятное, что на работе приложений сказывается не бизи, а время отклика/обслуживания.

    Вопрос в том, а опирается ли AIX в каких-то своих оптимизациях и тд и тп именно на tm_act% или он только для пользователя/администратора вычисляется?

Для ответа в этой теме необходимо авторизоваться.