сравнение результатов работы файловых систем в ос AIX и LINUX

Главная Форумы POWER Systems Виртуализация POWER сравнение результатов работы файловых систем в ос AIX и LINUX

Просмотр 22 веток ответов
  • Автор
    Сообщения
    • #11246
      kir
      Хранитель

      Добрый день!
      Я тут недавно был шокирован…
      Копировали (cp) 400Мб данных (куча мелких файлов) на AIX 6 внутри rootvg (локальные диски)
      время 7 мин. Этот факт смутил, решили пойти дальше…копировали на массив…vxfs меньше минуты тот же объем. Подумал что это баг 6 AIX, решили попробовать на AIX 5.3 …оказалось тотже объем 5 мин.
      Что любопытно на винде (персоналке) это занимало меньше 2 мин, на линуксе 3 сек. Я честно говоря в шоке. Тем более памяти на AIX просто немерянно, 7 ядер. А на линуксе все гораздо скромнее.
      Пробовали копировать один большой файл такого же объема на аикс, вышло около 10 сек.
      Получается что очень медленная работа ФС при мелких файлах, либо это особенность такой работы утилиты cp. Есть соображения, что можно подтюнить или объяснение такой работы ФС. Приложения были остановлены.

    • #11247

      Без зеркалирования локальные винты?
      Не могу адекватно проверить у себя, к сожалению, у меня все стоят на СХД…

    • #11248
      uxTuaHgp
      Участник

      исторически сложилось, что cp во всех юниксах очень медленно работает, поэтому когда нужно скопировать кучу мелких файлов с одного места на другое, используют
      $ find . |cpio -ov|(cd /somedir; cpio -idv)

      Попробуйте на вашем наборе данных и покажите публике результаты.

    • #11249
      Oldnick
      Участник

      интересно, а если в файловой системе десятки миллионов маленьких файлов, какая скорость обработки таких файлов в среде AIX ? 🙂
      например, если вдруг понадобиться эти файлы забэкапить на ленту…

    • #11253
      kir
      Хранитель

      При cpio 4 мин на AIX6.
      Зеркалирование есть, но оно не объясняет.
      Потому что при одинаковом объеме 1 большой файл и куча маленьких, время очень сильно отличается на AIX.
      Есть еще предположение, что линукс кеширует данные иначе.
      Т.е. по факту на диск еще не произошла запись, а он рапортует что cp выполнилась (а факту данные еще в кеше).

    • #11254
      Victor Sedyakin
      Участник

      Скорее всего, это особенность работы JFS/JFS2 с включенным журналированием.
      из редбука по поводу оптимизации JFS:
      [spoiler]The use of a JFS log allows for rapid and clean recovery of file systems if a
      system goes down. However, there may be a performance trade-off here. If
      an application is doing synchronous I/O or is creating and/or removing many
      files in a short amount of time, then there may be a lot of I/O going to the JFS
      log logical volume. If both the JFS log logical volume and the file system
      logical volume are on the same physical disk, then this could cause an I/O
      bottleneck. The recommendation would be to migrate the JFS log device to
      another physical disk.[/spoiler]

    • #11257
      Sever
      Участник

      интересно, а если в файловой системе десятки миллионов маленьких файлов, какая скорость обработки таких файлов в среде AIX ? 🙂
      например, если вдруг понадобиться эти файлы забэкапить на ленту…

      IMHO AIXовых систем с таким объемом файлов нет. Они просто не могут “дожить” до таких объемов.

    • #11274
      yota
      Участник

      При cpio 4 мин на AIX6.
      Зеркалирование есть, но оно не объясняет.

      Как это не обьясняет? Ещё как может обьяснить. Зеркалирование какое? LVM’ом? Тогда lslv того лог. тома, где все экскрименты были покажите.

    • #11277
      kir
      Хранитель

      Смотрите, копирование 1-го большого файла 400Мб на аикс 10сек
      тот же самый объем но кучей мелких файлов 7 мин.
      Если вы говорите про синхронизацию зеркал, то почему в обоих случаях она должна отличаться ведь объем размазываемый одинаков.
      bash-3.2# lslv hd3
      LOGICAL VOLUME: hd3 VOLUME GROUP: rootvg
      LV IDENTIFIER: 00f6216900004c000000012bc7f39b81.7 PERMISSION: read/write
      VG STATE: active/complete LV STATE: opened/syncd
      TYPE: jfs2 WRITE VERIFY: off
      MAX LPs: 512 PP SIZE: 128 megabyte(s)
      COPIES: 2 SCHED POLICY: parallel
      LPs: 48 PPs: 96
      STALE PPs: 0 BB POLICY: relocatable
      INTER-POLICY: minimum RELOCATABLE: yes
      INTRA-POLICY: center UPPER BOUND: 32
      MOUNT POINT: /tmp LABEL: /tmp
      MIRROR WRITE CONSISTENCY: on/ACTIVE
      EACH LP COPY ON A SEPARATE PV ?: yes
      Serialize IO ?: NO

    • #11282
      yota
      Участник

      chlv -d pr hd3 при размонтированной файловой.

    • #11283
      kir
      Хранитель

      Хотите сказать я после этого за 3 сек смогу скопировать как на линуксе? 🙂

    • #11284
      yota
      Участник

      Хотите сказать я после этого за 3 сек смогу скопировать как на линуксе? 🙂

      Нет, но должно пошустрее работать.

    • #11285
      uxTuaHgp
      Участник

      это не может играть решающей роли
      мне в общем тоже непонятно, почему AIX так медленно работает с FS.

    • #11292
      yota
      Участник

      это не может играть решающей роли
      мне в общем тоже непонятно, почему AIX так медленно работает с FS.

      Так проверять надо, чего гадать то. У меня это значительно ускорило работу. Можно ещё с nolog файловую смонтировать для интереса. А вообще на десятках миллионах файлов любая ФС будет не шустро работать.

    • #11296
      sdudnik
      Участник

      zfs смотрит на вас свысока)

    • #11297
      uxTuaHgp
      Участник

      В смысле уже на небесах?;)
      ZFS не повезло появиться в момент, когда IBM выпустил Power5, противопоставить которому SUN ничего не смог.
      К тому времени, кстати, в AIX уже давным давно присутствовал LVM.
      Надеюсь, у IBM припасен туз в рукаве, просто эфемерные лавры линукса и соляриса голубого гиганта не беспокоят.

    • #11298
      sdudnik
      Участник

      Ну да, не повезло, но тем не менее это неплохая фс, вполне удобная, с хорошими возможностями и интересной реализацией. Осталось портировать ее на линукс)

    • #11300
      kir
      Хранитель

      Смотрю уже флейм пошел. Давайте по делу писать. Попробуйте у себя тот же oracle_home скопировать, чтобы замерить время и примерно поймем в чем может быть проблема. Я вот думаю айбиэм-саппорт возмется за такую проблему или напишут что все ок, так и должно быть.

    • #11301
      uxTuaHgp
      Участник

      за спрос денег не берут
      пусть потрудятся

    • #11302
      andrewk
      Участник

      они скажут, что за PerfPMR деньги надо отдельно платить 😉

    • #11304

      можете сформулировать, как проводить тестирование? Думаю, если прийти к единому алгоритму, то будет полезная инфа от тех, кто его проведёт.
      От себя, наверное, смог бы потестить на JS22, PS701, 9119…

    • #11305
      kir
      Хранитель

      Да все просто:
      1. Берете кучу мелких файлов (например бинарники Oracle) определяете объем (утилитой du)
      и копируете:
      а. с локальной ФС на локальную (определяете время утилитой time)
      б. с локальной на массив (аналогично с замером времени )
      в. создаете 1 файл аналогичного размера равным этой куче файлов (набиваете нулями dd’ой )

      2. Делаете все тоже самое, на другой машине желательно с другой версией (уровнем обновления) AIX
      3. Тоже самое на другой платформе (Linux, Solaris)
      На линуксе желательно перед проведением очередного теста делать sync, я так понимаю он сбрасывает грязные блоки на диск. Чтобы данные читались не из кеша.
      Желательно, чтобы машины не использовались высоконагруженными приложениями (чтобы исключить их влияние).
      Если дисковые ресурсы в LPAR попилены через виос (это тоже желательно указать).

    • #11306
      andrewk
      Участник

      sync не сбрасывает блоки на диск. sync дает команду сбросить блоки на диск.

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