// codeart.ru / Вопрос/Ответ / Про медленное копирование файлов в HPUX Форум

Про медленное копирование файлов в HPUX rss подписка

Автор: Evgeniy Sergeev

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

В HPUX используется журналируемая файловая система, разработанная компанией Veritas — VxFS, также JFS или OnlineJFS. VxFS — это одна из лучших файловых систем. К ее достоинствам можно отнести: быстрое восстановление после сбоя, конфигурирование «на лету», возможность создавать моментальный снимок файловой системы (snapshot), возможность хранения больших файлов (до нескольких терабайт) и т.д. Но есть и недостатки, один из них — это фрагментация данных расположенных на диске.

Вообще, проблемы с фрагментацией могут иметь разную природу. Во-первых, возможно фрагментация свободного месте на диске, когда для размещения новых данных чисто физически не может быть выделено несколько последовательных блоков для создания экстента (VxFS — файловая система, которая строится на базе экстентов). Во-вторых, возможна ситуация, когда в процессе расширения файла он становится сильно фрагментированным. В любом случае, фрагментация данных способна значительно уменьшить скорость чтения/записи данных.

Чтобы исключить влияние фрагментации на скорость копирования, я проанализировал файловую структуру. О том как это сделать можно прочитать в статье «Решаем проблемы с файловыми структурами на HPUX». Если коротко, то необходимо проверить сколько экстентов в файловой структуре имеют небольшое количество блоков. Для этого выполняется следующая команда:

fsadm -F vxfs -de /oradata

Затем анализируются параметры:

% Free blocks in extents smaller than 64 blks: 0.61
% Free blocks in extents smaller than 8 blks: 0.05
% blks allocated to extents 64 blks or larger: 98.14

Если количество экстентов, у которых меньше 8 блоков, больше 5%, то дела плохи. Нужно выполнять дефрагментацию. Для этого запускаем команду:

fsadm -F vxfs -DE /oradata

Процесс долгий и ресурсоемкий, поэтому запускать его лучше во время наименьшей нагрузки на сервер.

В моем случае фрагментации данных не было. Несмотря на это, я на всякий случай запустил процесс дефрагментации, но, как и следовало ожидать, увеличение производительности в процессе копирования данных не произошло. Тогда, решив, что отрицательный результат — это тоже результат, я продолжил копать в сторону оптимизации работы файловой структуры.

Здесь стоит ознакомиться с документом HP UX VxFS tuning and performance (.pdf). По крайней мере, я с него и начал. Прочитав внимательно документ, я обратил внимание, что Оракловый раздел смонтирован с опциями: «mincache=direct, convosync=direct«. А это значит, что все операции с дисковой подсистемой выполняются напрямую, причем синхронно! Эти опции, конечно же, появились не случайно. Существует еще один документ от HP, который поясняет почему данный раздел смонтирован таким образом — HP UX VxFS mount options for Oracle Database environments. Подозревая, что именно Direct I/O являются причиной замедления при копирования данных, я решил проверить с какой скоростью будет идти копирование без данных опций.

После отключения скорость копирования возросла в пять раз. На сколько я знаю, «cp» может считывать данные блоками до 1024 килобайт, поэтому, даже при включенном Direct I/O, чтение не должно сильно замедлять скорость копирования. Подозреваю, что проблема возникает в момент записи данных, когда система ожидает завершение предыдущей команды, чтобы бы записать следующую порцию данных.

В итоге я решил вопрос следующим образом — на Оракловом разделе оставил опции монтирования такими как и были, а копию базы откидываю в соседний раздел, смонтированный без использования Direct I/O. В результате база копируется в несколько раз быстрее.

Leave a Reply

« »