Переход с Solaris на Linux снижает скорость резервного копирования 80%. Помогите мне вернуть прежнюю скорость?

Вы использовали sar или iostat для мониторинга производительности диска во время резервного копирования, чтобы увидеть, что Linux думает о производительности диска?

А как насчет использования какой-нибудь утилиты для тестирования производительности в файлах? Я только что придумал это, так что это, вероятно, ужасный способ сделать это, и это действительно было бы просто для последовательного чтения, но:

sudo dd if=/u1/some_large_file of=/dev/null

По сути, если вы используете утилиту сравнения для дублирования чтения всех маленьких файлов, вы можете сделать это, если это диск, и перейти оттуда.

Следующее больше не актуально:
Если с 20 кбит / с вы имеете в виду килобиты, если я не испорчу это, потому что рано утром, ваши цифры не складываются. Вы сказали, что у вас 2,1 терабайта со скоростью 20 кбит / с:

Даже если это был всего 1 терабайт:

1 TB = 8589934592 bits
8589934592 / 20 (bits a second) = 429496730 seconds
429496730 / 60 (seconds) = 7158278 minutes
7158278 minutes / 60 = 119,304 Hours
119,304 / 24 = 4971 (Days)

Или, если вы имели в виду килобайты:

1 terabyte = 1073741824 kilobytes
1073741824 / 20 kB/s = 53687091 seconds
53687091 seconds = 621 days

Я испортил эти расчеты? (придется постыдно удалить мой пост, если я:-))

Какую файловую систему вы используете на томе LVM?

и как хранятся 10 миллионов небольших файлов - все в одном каталоге (или небольшом количестве каталогов) или распределяются по многим каталогам и подкаталогам? ("многие" - произвольно большое число)

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

например, ext2 или ext3 без включенной функции dir_index (IIRC, dir_index используется по умолчанию для ext3 уже несколько лет. Это очень помогает, но не устраняет проблему полностью).

Вы можете использовать tune2fs для запроса и / или установки функции dir_index для ext3. например, для запроса:

# tune2fs -l / dev / sda1 | особенность grep
Особенности файловой системы:      ext_attr resize_inode dir_index тип файла sparse_super

если вы не видите dir_index в этом списке, то вам нужно включить его так:

и установить:

# tune2fs -O dir_index / dev / sda1
tune2fs 1.41.8 (11 июля 2009 г.)

(да, tune2fs только отвечает здесь, печатая номер своей версии... не заботится о том, была ли операция успешной или неудачной. не хорошо, но, вероятно, она выдаст ошибку в случае неудачи)

И наконец: если это действительно является проблемой, и включение dir_index не помогает, тогда вам, вероятно, следует рассмотреть возможность использования другой файловой системы. XFS - хорошая файловая система общего назначения, и у AFAIK ext4 такой проблемы нет. любой из них был бы разумным выбором для замены fs (хотя ext4 является довольно новым и хотя многие люди используют его без проблем, я не уверен, что пока доверю этому на производственных серверах)

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

Гораздо более вероятно то, что указал Крейг, большие каталоги ухудшают производительность. Linux is somewhat notorious for not handling the large-directory problem well. VxFS can handle up to 100K files/directory quickly, where ext2/ext3/reiserfs generally start slowing down well before then. This is one area where a poor choice in filesystem for migration target can seriously impair your backup performance.

That said, if this is your problem, just plain old access into and out of those directories should also be impaired. It may be the difference between 80ms to open a file and 210ms, which is barely perceptible to end-users, but it should be there.