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


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

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

  • Автор
    Сообщения
  • #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 дает команду сбросить блоки на диск.

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