Я запускаю простую команду rsync между двумя серверами. Оба сервера имеют два интерфейса eth при связывании. Когда я отправляю большой файл с одного сервера на другой с помощью rsync, я достигаю скорости передачи 130 Мбит / с.
Но, и вот в чем проблема, когда я отправляю каталог с большим количеством небольших файлов, скорость передачи в лучшем случае составляет 1 Мбит / с.
Я проверил обе нагрузки на ЦП (8 ЦП i7), и они составляют максимум 10%.
Зная, что то, что замедляет всю передачу, - это открытие / закрытие файлов, и это «теоретически» происходит на процессоре, я понимаю, что это можно легко настроить. Но я не знаю, как это настроить.
Любой совет о том, как заставить rsync использовать все процессоры?
Ваша проблема не имеет (почти) ничего общего с процессором.
Передача больших файлов обычно выполняется быстро, так как это может быть выполнено с помощью последовательного ввода-вывода.
Для передачи большого количества небольших файлов требуется много лошадиных сил на стороне хранилища, поскольку для этого требуется случайный ввод-вывод. Необходимы малое время поиска, быстрые жесткие диски, большой объем кеша и файловая система, рассчитанная на огромное количество файлов. CPU там не помогает, по крайней мере, не сильно, как вы и наблюдаете. ЦП и ОС просто ждут завершения дискового ввода-вывода.
Все, что может сделать более быстрый ЦП / большее количество ядер, что они могут в конечном итоге ожидать более быстрого ввода-вывода. :-)
Задержка многих мелких случайных операций ввода-вывода складывается:
По моему опыту, rsync - очень хороший инструмент для синхронизации, но не очень хороший инструмент для максимально быстрой отправки всех данных. Используйте его, когда пропускная способность или емкость хранилища не оставляют других вариантов. Если вы можете позволить архивировать все файлы и передавать их в одном большом двоичном объекте, вы можете рассчитывать на повышение производительности (общее время настенных часов, используемое для завершения операции), если файлов достаточно.
При работе с большим количеством небольших файлов с помощью rsync возникают большие накладные расходы на сеть / диск. С достаточно маленькими файлами коэффициент ускорения может быть меньше 1.
Обратите внимание на коэффициент ускорения с помощью -v. Если ваш коэффициент ускорения ниже 1, даже если вы знаете, что уже синхронизированы, значит, вы испытываете довольно много накладных расходов. ЦП не является узким местом.
Что сказал Янне: вы привязаны к вводу-выводу, а не к процессору. Запустите top (а лучше, поверх / htop), обратите внимание, как мало на самом деле используется процессор при передаче небольших файлов. Также обратите внимание, что ваши процессы находятся в состоянии «D», ожидая, когда для них будут доступны данные.
Кроме того, я не верю, что rsync оптимизирован для многоядерных процессоров; большая часть того, что он делает, является последовательным, и потребуется очень умная работа, чтобы заставить его работать быстрее в этом отношении.
Однако он, вероятно, использует до 2 ядер, если вы используете ssh в качестве транспорта. Он будет порожден как отдельный процесс и будет выполнять все операции по шифрованию и, возможно, сжатию в отдельном потоке от основного процесса rsync. Этот процесс имеет несколько задач, требующих интенсивной загрузки ЦП: вычисление CRC и хеширование MD5 (я считаю, что это то, что он использует).