Что держит одну сторону rsync такой занятой?

В моей локальной сети есть компьютер Debian, служащий резервным сервером для остальных. Он имеет четыре жестких диска, объединенных в программный RAID 5 md, на этом LVM и на этом btrfs. Резервное копирование выполняется с помощью rsync, а для большой файловой системы требуется более часа. Долгое время я думал, что мало что смогу с этим поделать.

Недавно, однако, я заметил, что активность HDD сильно отличалась на обоих концах передачи. В то время как отправляющая сторона, использующая Gentoo и в основном использующая ext4, почти не имела дискового ввода-вывода, принимающая сторона была постоянно занята. Поскольку большая часть данных не меняется между передачами, я считаю, что чтение метаданных должно составлять основную часть данных. Но я был бы очень удивлен, если чтение inode-ов в btrfs - это такая большая работа, чем делать то же самое в ext4.

iotop на принимающей стороне было подтверждено чтение диска со скоростью около 1–4 МБ / с, тогда как на стороне-отправителе был только случайный пакет 0,5 МБ / с.

У меня вопрос, может кто-нибудь объяснить, что здесь происходит? Желательно с некоторыми указаниями, как обойти проблему, если это возможно.

Возможно, есть какой-то флаг настройки btrfs, который я мог бы использовать, или что-то подобное. Мне нужна FS с возможностью создания моментальных снимков на сервере резервного копирования, и моя попытка использовать FreeBSD и ZFS быстро привела к несовместимой FS, поэтому в данный момент я вижу небольшую альтернативу btrfs. Поэтому ответы, говорящие мне об использовании ext4 или zfs, могут получать голоса, но без галочки.

Используемые параметры Rsync, в соответствии с запросом cjm :

--rsync-path='rsync --fake-super'
--archive               # -rlptgoD
--hard-links            # detect and preserve these
--acls
--xattrs
--sparse
--noatime               # based on patch from samba #7249c1
--delete
--delete-delay
--fuzzy
--human-readable        # size suffixes, base 1000
--stats

А также набор -fправил, чтобы пропустить некоторые файлы.

Опции монтирования btrfs сообщаются mountкак

rw,nosuid,noexec,noatime,nospace_cache

В частности, это включает noatimeфлаг, поэтому не должно быть никакой записи, если только в некоторых файлах не было различий. Я добавил эту информацию в ответ на ответ по Kyle Jones .

performance rsync io mdadm btrfs MVG
источник

Какие параметры rsync вы используете?

CJM

Просто сделав снимок в темноте, у вас есть неисправный диск? Это может привести к дополнительным операциям ввода-вывода, поскольку он пытается восстановить отсутствующие данные из информации о четности.

Багамат

@bahamat, у меня работает smartd, и он не сообщил о проблемах. Также mdadm не сообщал о каких-либо событиях.

MvG

Сложно сказать наверняка, что не так. Только один пример - несоответствующие размеры блоков среди слоев. Для того, чтобы диагностировать это, вам лучше всего использовать что-то вроде dtraceили systemtapузнать, на что тратится время.

Багамат

@ bahamat, это проспект, который я еще не исследовал. Можете ли вы написать ответ о том, как использовать эти инструменты для диагностики проблемы? Это было бы прекрасно. Пошаговые инструкции, если у вас есть время, но даже некоторые грубые идеи и указатели документации будут очень полезны.

MvG

Один из возможных ответов заключается в том, что удаленная файловая система по умолчанию монтируется с опцией «atime». Время доступа записывает для всего, что удаленный доступ к rsync в сочетании со штрафом на запись, который вы испытываете с RAID 5 (вычислительная четность означает чтение всех дисков RAID до того, как вы запишете на один из них), может объяснить увеличение ввода-вывода на удаленной стороне.

Если я прав, вы можете ускорить процесс, установив удаленную файловую систему с опцией «noatime».

Кайл Джонс
источник

Хорошая мысль, но, к сожалению, не решение: файловая система уже смонтирована noatime. Mount сообщает набор всех параметров монтирования как rw,nosuid,noexec,noatime,nospace_cache.

MvG

Что держит одну сторону rsync такой занятой?

Ответы: