Как ускорить rsync / tar большого Maildir?
У меня очень большой Maildir, который я копирую на новую машину (более 100BASE-T) с помощью rsync. Прогресс медленный. ОЧЕНЬ МЕДЛЕННО. Как медленный 1 МБ / с. Я думаю, это потому, что очень много маленьких файлов читаются в порядке, который, по сути, является случайным по отношению к тому, где блоки хранятся на диске, вызывая массовый шторм поиска. Я получаю аналогичные результаты при попытке смолить каталог. Есть ли способ заставить rsync / tar читать в порядке дисковых блоков или иным образом решить эту проблему?
Редактировать: я пробовал tar cf / dev / zero Maildir /, и на старой системе это заняло 30 минут ! На новой системе, когда rsync наконец завершился, тот же тест занял 18 минут. Дамп того же каталога в старой системе занял 8 минут, а в новой системе дамп -0f / dev / zero -b 1024 / home / psusi / Maildir / закончен всего за 30 секунд.
3 ответа
В итоге я написал небольшой скрипт на python, чтобы вычислить корреляцию между именами каталогов и inode, инодами и блоками данных и именами каталогов с блоками данных. Оказывается, что ext4 имеет тенденцию иметь довольно слабую корреляцию между порядком, в котором имена файлов появляются в каталоге, и тем, где они хранятся на диске. После обсуждения в списке рассылки ext4 выясняется, что это результат хешированных индексов каталогов, используемых для ускорения поиска в больших каталогах. Имена хранятся в порядке хеширования, что эффективно скремблирует их порядок относительно всего остального.
Мне и, по крайней мере, еще одному комментатору кажется, что это недостаток фс, который следует исправить. Тед Цо (сопровождающий ext) считает, что в fs это будет слишком сложно, и что хорошие инструменты (такие как rsync и tar) должны иметь возможность сортировать каталог по номеру инода перед чтением файлов. ]
Похоже, что запросы на расширение возможностей должны быть поданы для rsync и tar.
Несколько моментов для рассмотрения:
-
Сколько файлов мы говорим?
find /path/to/your/maildir/ | wc -lдолжно дать вам приблизительное указание. Сотни тысяч должны быть в порядке. Сотни миллионов людей могут предложить вам обрезать, заархивировать и вообще очистить. -
Диск медленный? Существует множество доступных тестов, таких как всеобъемлющий
bonnie++и быстрый и простой тест производительности Disk Utility. Запустите один и посмотрите, страдаете ли вы.- Это может вызвать проблемы с оборудованием - заменить что-то более быстрое
- Проблемы с файловой системой - используете ли вы что-то, о чем известно, что оно очень медленное при высоких IOPS при случайном чтении?
[ 1112]
Но, в конечном счете, tar вызов, а затем передача должен дать вам наилучшую общую пропускную способность за счет того, что вам нужно быть там, чтобы настроить передачу после того, как вы сгенерировали tar.
Попробуйте отключить отслеживание времени или использовать относительное время на новом разделе диска. Это ограничит накладные расходы. Переход от файловой системы без журналирования, такой как ext2, к журналируемой файловой системе, такой как ext3 или ext4, приведет к некоторому снижению производительности
Когда я переместил Maildirs, я выполнил подготовительный rsync, чтобы заблаговременно получить все каталоги на месте , Тогда оставались только обновления.
Когда вы будете готовы сделать настоящий шаг, вы можете убедиться, что каталоги стабильны.
- переводят демон SMTP в режим «только очередь»,
- отключают запуск очереди демоном SMTP и
- отключают доступ пользователя.
Повторная активация после перемещения файла.
РЕДАКТИРОВАТЬ: Я думаю, что вы определили проблему. Tar и rsync оба пройдут по каталогам. Из-за обычных изменений файлов в Maildir файлы для каждого каталога будут разбросаны по всему диску. Такой инструмент, как dump, считывает раздел в порядке блоков, но повторяет проблему на новый раздел. Второй rsync должен работать намного быстрее второго.