Нет, реальное поведение непредсказуемо, но есть вероятность, что несколько экземпляров попытаются скопировать один и тот же файл одновременно, и пропускная способность будет потрачена впустую, и могут случиться плохие вещи.
Однако, хитрое использование --include и --exclude может быть удобно здесь:
rsync -avP \
--include '*/' --include '[a-g]*' --exclude '*' \
source.host:path/to/source/ path/to/dest/
Эта команда будет отправлять только те файлы, которые начинаются с букв от a до g . Вы можете настроить параллельные передачи для других частей алфавита.
Наконец, когда все передачи завершены, вы должны снова запустить исходную команду rsync (обратите внимание, что я оставил --remove-source-files вне моей команды), чтобы убедиться, что любая странность, которая произошла, сглаживается, и любые файлы оригинальные фильтры пропущены (точечные файлы, возможно?) переданы также.
Кстати, всегда ставьте последнюю косую черту в каталогах источника и назначения (например, path/to/dest/), иначе rsync может не выполнить то, что вы ожидаете!
Однако rsync - не самый эффективный способ репликации файлов в первый раз, особенно когда задержка высока (в основном это предназначено для последующих этапов обновления).
Вам было бы гораздо лучше использовать tar для потоковой передачи данных в ssh:
ssh source.host tar -C path/to/source/ cfj - . | tar -C path/to/dest/ xfj -
Это позволит упаковать и сжать данные в непрерывный поток, направить их через ваш ssh туннель, обратно в tar на локальном конце и снова развернуть в файлы, все в одной команде, без того, чтобы файл tar когда-либо касался диска.
Недостатком является то, что это не легко восстановить, если соединение обрывается.
Tar также имеет опцию --exclude (но не --include), поэтому при необходимости вы можете паралелизировать потоки аналогичным образом. Опять же, вы, вероятно, должны закончить с rsync, чтобы проверить передачу.
За исключением: "природа TCP" не является проблемой здесь. TCP использует схему скользящего окна, которая должна насыщать канал с любой нормальной задержкой, и есть ручки, которые можно переключать, если это не так.
Природа rsync, однако, заключается в том, что он должен переписываться о каждом файле, перед тем как передать его, и задержка здесь будет вредной (хотя реализация использует конвейеризацию для минимизации этого).
Если вы не насыщаете свою ссылку, то первое, что нужно попробовать, это убрать rsync из уравнения (scp из достаточно большого файла). Если это все еще не делает, то проверьте использование вашего процессора: сжатие и шифрование могут быть узким местом. Если передача простых данных через Netcat (или устаревший FTP) не может этого сделать, возможно, вам нужно настроить TCP. Также проверьте ping на потерю пакетов, так как это действительно испортит TCP. Наконец, возможно, самое медленное звено в цепочке не ваше.
