Я протестировал 10-гигабитное соединение между двумя хостами, чтобы иметь возможность читать 10-гигабайтный файл с host1 и записывать его на host2 с помощью netcat, где скорость была 410 МБ / с.
Когда я снова отправляю / получаю ZFS с помощью netcat через то же выделенное соединение 10 Гбит / с, я получаю только 70 МБ / с. Снимок размером 2,5 ТБ с 15 миллионами файлов.
Вопрос
В чем может быть причина этого замедления? Узким местом является то, что откат моментального снимка с таким количеством файлов занимает много времени, или количество файлов не влияет на скорость отката ZFS?
Обновить
Тест передачи файлов 10 ГБ, где я получил 410 МБ / с, я полагаю, имитирует отправку / получение ZFS с откатом. Исходя из этого предположения, я очень удивлен, что вижу такие разные скорости. Я использую скорость для сравнения двух тестов, поэтому мне не нужно создавать файл размером 2,5 ТБ со случайными данными.
Поэтому я не понимаю, почему «чтение файла с хоста 1, передача с помощью netcat, запись файла на хост 2» намного быстрее, чем «zfs отправить снимок с хоста 1, передать с помощью netcat, получить / откат ZFS на хост 2».
Может быть, другой способ спросить то же самое было бы ?:
Если у меня есть два снимка одинакового размера по 2,5 ТБ, где снимок 1 содержит 1 файл, а снимок 2 - 15 миллионов файлов. Будет время для zfs receive для них обоих быть одинаковыми? Или один будет быстрее другого?
Количество файлов и каталогов, участвующих в потоке отправки / получения zfs, не должно иметь прямого влияния на скорость его передачи. Косвенно может, потому что обычно верно сказать, что «распространение» набора данных по вашим дискам будет выше с большим количеством каталогов / файлов, в зависимости от рабочей нагрузки, которая их породила. Это важно, потому что для жесткого диска гораздо проще выполнять последовательное чтение, чем произвольное чтение - и если рассматриваемый поток проходит по всем дискам, это будет гораздо больше рабочей нагрузки случайного чтения, чем последовательного.
Кроме того, насколько я понимаю, метаданные ZFS используются в файлах в файловых системах ZFS (не в zvols); У меня нет прямых цифр, но я бы не удивился, если бы один файл размером 2,5 ТБ имел в целом значительно меньше связанных с ним блоков метаданных, чем 2,5 ТБ, заполненных 15 миллионами файлов. Эти (потенциально многие) дополнительные блоки метаданных добавят больше данных, которые необходимо прочитать, таким образом, будет происходить большее чтение (и, возможно, поиск) с диска. Итак, да, вполне вероятно, что косвенно поток отправки, состоящий из 15 миллионов файлов, может быть медленнее для создания, чем поток, состоящий из одного файла того же размера (особенно если этот один файл был создан сразу, как последовательная запись, на бассейне с большим количеством непрерывного свободного пространства в то время).
Потоки ZFS send / recv, которые отправляются без буферизации, очень часто имеют очень нестабильную производительность - иногда кажется, что они идут довольно быстро, а затем почти полностью исчезают в течение потенциально длительных периодов времени. Это поведение было описано и даже до некоторой степени проанализировано на различных форумах в Интернете, поэтому я не буду вдаваться в подробности. Общий вывод заключается в том, что, хотя ZFS может и должна проделать некоторую работу по повышению эффективности внутреннего рабочего процесса, «быстрое решение» многих проблем - это введение буфера на отправляющей и принимающей стороне. Для этого наиболее распространенным инструментом является mbuffer.
Если передать ваши zfs через mbuffer перед netcat (и снова через mbuffer перед zfs recv), вы должны увидеть заметное улучшение, если основная проблема заключается в том, с чем может помочь добавление буфера. У Аласдэра есть краткое описание этого в своем блоге - на данный момент у меня ничего не опубликовано по этой теме, поэтому я покажу вам его: http://blogs.everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/
Причина большой разницы в скорости в том, что нельзя сравнивать передачу файла и снимка. Файл - это последовательный ввод-вывод, а моментальный снимок - это случайный ввод-вывод, так как он содержит измененные блоки.