Как это может быть?
Запуск cp или rsync (с -W --inplace) занимает два часа для 93 Гб; восстановление ленты по выделенной резервной сети занимает 41 минуту. Восстановление ленты составляет 50 Мб/с; диск на диск был измерен и рассчитан как максимум 16 Мб/с - 2 Мб/с, если ЦП занят.
Программное обеспечение для восстановления — Veritas NetBackup; диски находятся на массиве EMC Symmetrix по оптоволокну. Устройство — HP rx6600 (Itanium) с 16 Гб, работающее под управлением HP-UX 11i v2. Все диски находятся на одной оптоволоконной карте, указанной как:
HP AD194-60001 PCI/PCI-X Fibre Channel 2-port 4Gb FC/2-port 1000B-T Combo Adapter (FC Port 1)
Все диски также используют Veritas Volume Manager (вместо HP LVM).
Обновлять:Мне приходит в голову, что этонетпросто прямое копирование с диска на диск; на самом деле этоснимокна копию диска. Может ли чтение снимка так сильно замедлять работу? Снимок — это снимок HP VxFS (не vxsnap); возможно, взаимодействие между снимком и VxVM приводит к снижению скорости?
Обновлять:Используя fstyp -v, выясняется, что размер блока (f_bsize) равен 8192; размер блока UNIX по умолчанию равен 512 (или 8192/16). При тестировании с dd я использовал размер блока 1024k (или 1048576, или 8192*128).
Мне действительно интересно, не из-за размера ли блока. Я прочитал на PerlMonks, что модуль Perl File::Copy быстрее, чем cp; это интригует: интересно.
Если NetBackup использует tar, то этонетиспользование cp: это также может объяснить увеличение скорости.
Обновлять:Похоже, что чтение из снимка почти в два раза медленнее, чем чтение с реального устройства. Запуск cp медленный, как и запись tar в командную строку. Использование tar немного лучше (при использовании файла), но ограничено файлами размером 8 ГБ (файл, о котором идет речь, имеет размер около 96 ГБ). Использование File::Copy из perl с томом, не являющимся снимком, кажется одним из самых быстрых способов.
Я попробую это сделать и сообщу здесь, что у меня получилось.
решение1
Другой вопрос, связаны ли вы с вводом-выводом внутри сети FC, спросите ребят из SANпродемонстрировать(графики хорошие)действительныйДоступна резервная полоса пропускания (и если коммутаторы FC — это коммутаторы Cisco, как они обеспечивают отсутствие проблем с полосой пропускания внутри коммутатора)
решение2
Ограничены ли вы чтением и записью на один и тот же диск в массиве?
решение3
Если ваша лента также находится в SAN, то вполне возможно, что xfer передается и переходит напрямую с ленты на диск, в то время как копия должна передаваться через хост, выполняющий копирование, и поэтому процесс идет медленнее.
решение4
Если диски подключены к разным шинам на материнской плате, данные могут копироваться по 3 или более внутренним шинам, и задержка убивает ваш ввод-вывод для копирования с диска на диск. В этом случае вполне возможно, что сетевой ленточный накопитель изначально имеет более высокую пропускную способность пути к целевому диску, чем исходный диск.