LINUX.ORG.RU

Linux и копирование больших файлов, часть 100500

 , ,


2

6

Есть у меня файлопомойка в виде ноута, подключенного к гигабитной LAN. На файлопомойке массив 4x2T, подключенный через ExpressCard-ный однопортовый SATA2-контроллер(!) и SATA port multiplier. На массиве btrfs и RAID5, но это вроде как не важно.

Пропускная способность этой офигительной матрёшки из интерфейсов при линейном I/O — 120 MiB/s, т. е. по 30 MiB/s на диск. Учитывая RAID5 — полезных 90 MiB/s суммарно. Это всё проверялось с помощью dd на чтение; полагаю, на запись цифры не должны сильно отличаться. Пропускная способность сети примерно такая же (замерял iperf3).

А теперь собственно проблема. Я копирую некий большой файлик по сети через rsync-over-ssh и вижу, что диск загружен примерно 25-30% времени. Если смотреть на загрузку CPU, то всё соответствует: сначала загрузка CPU где-то 40% (особо отмечу — я не упираюсь в CPU из-за ssh) и ноль iowait, потом внезапно 100% iowait и шуршание дисками. В итоге скорость копирования получается ~25-30 MiB/s и ещё проседает время от времени.

Вопрос: как это исправить? Я хочу, чтобы не простаивали ни диск, ни сеть. Ядро на файлопомойке 4.6.2 стоковое арчовское.

★★★★★

Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от intelfx

скорость ssh IMHO сильно зависит от задержек в сети.

Не пробовал залить большой файл по сети через nc ?

vel ★★★★★
()

сначала загрузка CPU где-то 40% (особо отмечу — я не упираюсь в CPU из-за ssh) и ноль iowait, потом внезапно 100% iowait и шуршание дисками

У тебя система на сервере сначала кэширует, потом сбрасывает на диск, есть мнение, что это драйвер ФС.

King_Carlo ★★★★★
()

ssh буффера. Как-то было: esxi, обслуживание одного из серверов, нет лив-миграции ессно, переливаю образы по scp - скорость оставляет желать лучшего (точно уже не помню давно было). быстрее получалось консолью слить себе а потом на целевой сервер. Возможно реализация ssh в esxi другая и я неправ.

VKraft ★★
()
Ответ на: комментарий от vel

Блин, и вправду, pv|lzop|nc...nc|lzop|pv показывает ожидаемые 75-80 MiB/s.

(Я ещё попробовал по nfs. Лучше бы не пробовал: LA=4, скорость ~ 5 MiB/s. Почему?)

intelfx ★★★★★
() автор топика
Ответ на: комментарий от VKraft

забыл добавить. загрузка ИО и ЦПУ была небольшая при этом.

VKraft ★★
()
Ответ на: комментарий от King_Carlo

Я вижу. Но writeback-подсистема в ядре одна на всех. Плюс когда-то давно с XFS+lvm2 я имел практически те же самые проблемы. Так что дело наверняка не в ФС.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от vel

А, нет: к середине трансфера всё то же самое, скорость 30 MiB/s.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

А куда смореть про «over ssh»?

В общем, я имел в виду вот так попробовать при копировании rsync ... -e «ssh -T -c arcfour -o Compression=no -x» ...

Bebop ★★
()
Ответ на: комментарий от Bebop

Этсамое...

For remote transfers, a modern rsync uses ssh for its commnications

Т. е. когда я пишу user@host:/dest, оно само соединяется через ssh. Компрессия у меня выключена, в качестве блочного шифра ChaCha20, который вроде как очень быстрый. В любом случае, я не упираюсь в CPU.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

Она async

Ой.
Ну, все равно стоило спросить.

thesis ★★★★★
()

А состояние буферов VFS в момент, когда начинает тормозить запись какое? Точнее интересует в последний момент до того, как начнет тормозить? (проверять нужно без ssh)

По поводу NFS - народ ускоряет nfs так -

a) Указываеием больших буферов на чтение/запись b) Использованием TCP вместо UDP (или наоборот)

c) отключением блокировок.

d) nfsvers=X где X=2 или 3

По моему опыту sync/async влияют только если буферы маленькие и версия сервера <= 3. Что забавно, NFS клиент из WinXP умудряется работать значительно быстрее, чем максимально затюнингованый линуксовый, что для меня загадка. У меня дефолтный NFS на гигабите PC <-> NAS (LVM на 5 разнокалиберных винтах от 500GB до 3.5TB) показывает 40MB/s иногда до 65MB/s.

slapin ★★★★★
()
Ответ на: комментарий от intelfx

И ещё, если не трудно, то проверьте буферы какого-нибудь неприличного размера, вроде --sockopts=SO_SNDBUF=10240000,SO_RCVBUF=10240000

Bebop ★★
()
Ответ на: комментарий от post-factum

Перечитай интервью с Коливасом. CFS запилили назло, чтобы не брать -ck2. То, что первые упоминания о 12309 появились в 2008 году, не случайно!

ZenitharChampion ★★★★★
()
Ответ на: комментарий от intelfx

Потому что меняется механизм буферизации. Но как хотите, я не настаиваю. Это вроде дефолтная опция при локальном rsync-е, но при копировании по сети не включается.

-W, --whole-file

With this option rsync’s delta-transfer algorithm is not used and the whole file is sent as-is instead. The transfer may be faster if this option is used when the bandwidth between the source and destination machines is higher than the bandwidth to disk (especially when the «disk» is actually a networked filesystem). This is the default when both the source and destination are specified as local paths, but only if no batch-writing option is in effect.

Bebop ★★
()
Ответ на: комментарий от intelfx

Забавно. Значит, background нужно ставить по скорости носителя, т.е., в районе 120 МиБ/с для HDD.

post-factum ★★★★★
()
Ответ на: комментарий от intelfx

disktop.stp из состава systemtap, например. а вообще тут есть на эту тему.

EvgGad_303 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.