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

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

Просмотр 12 веток ответов
  • Автор
    Сообщения
    • #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% или он только для пользователя/администратора вычисляется?

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