При записи на диск (SATA) я заметил, что tar, похоже, сильно ударил по производительности. Я пытаюсь скопировать относительно большой файл .dmg (556 МБ) с моего клиента (OSX) через локальную сеть как часть резервной копии на мой сервер (debian). При использовании типичного метода результаты были довольно плохими с точки зрения скорости передачи данных от клиента и ввода-вывода на сервере.
Для мониторинга ввода / вывода на сервере использовались: iostat -Ndx 1 и iotop -oa
scp: ~18 minutes пропускной способности на клиенте ~500KB/s-540KB/s на сервере ~800kB/s-1100kB/s (time scp <my_file> user@host:/path/to/dir/)
sftp: ~ 50% быстрее ~9 minutes пропускной способности на клиенте ~1MB/s МБ / с ввода-вывода на сервере ~1500kB/s-2000kB/s но не может быть написано в сценарии, так как я использовал графический интерфейс cyberduck
Дополнительные исследования дали этот пост, и поэтому я попробовал следующее:
На клиенте:
(tar -cf - <my_file> | pv -s $(du -sb <my_file> | awk '{print $1}') | nc -l 8888)
На сервере:
(nc <source_ip> 8888 | tar xf -)
ПРИМЕЧАНИЕ. Я прекратил использование pigz так как, по-видимому, пропускная способность клиента часто снижалась до 0 Kb/s во время передачи.
Это дало наихудшие результаты - около ~33 minutes при пропускной способности на клиенте ~300-400KB/s и вводе / выводе на сервере ~800-1200KB/s которые за последние 5 минут упали до ~200KB/s и я / O ~800KB/s соответственно.
Чтобы убедиться, что это не сеть, я изменил сервер на (nc <source_ip> 8888 > /dev/null) и время передачи сократилось до ~2minutes с пропускной способностью клиента ~6-7MB/s .
В результате дополнительных поисков на странице справки я решил изменить размер блока (-b, --blocking-factor) на более высокие значения, т. Е. 128, 512, 1024 и т.д., Что дало гораздо лучшую производительность записи при сопоставлении -b1024 с тест перенаправления в /dev/null . Справочная страница выглядит довольно устаревшей, любая ссылка относится только к изменению этой опции по отношению к записи на ленту и не упоминает современные медиа. Возможно ли, что для этого существуют негативные последствия для целостности данных? С помощью этой модификации и в соответствии с man-страницей я предполагаю, что tar пытается записать данные блоками по 512 байт, поэтому изменив их на 512 * 1024, то есть блоки по 512 КБ, я не знаю, возникнет ли проблема для ОС, чтобы написать это.
Редакция:
Первоначально размещены вдали от компьютеров, поэтому я обновил фактические используемые команды, предоставил более точное время и исправил опечатки. Также попробовал предложенное шифрование scp как предложено ниже и включил результаты
scp: ~17.5 minutes пропускной способности на клиенте ~500KB/s-540KB/s на сервере ~1100kB/s-1500kB/s
(scp -C <my_file> user@host:/path/to/dir/)
с измененным размером блока: ~42 seconds пропускная способность на клиенте и I/O на сервере ~15MB/s
клиент: (tar --disable-copyfile -cf - <my_file> | pv -s $(du <my_file> | awk '{size = $1 * 512} END {print size}') | nc -l 8888)
сервер: (nc 10.0.1.28 8888 | tar -b1024 -xf -)