Skip to main content

Проблемы с производительностью пары zfs send/receive по сети.

В продолжении вот этого поста.

При восстановлении снимка на другой машине через ssh (rsh аналогично) нарвались на проблему с низкой пропускной способностью всего комплекта (zfs send, ssh, zfs receive). Быстрый анализ привел к этой дискуссии.

Проблема хорошо описана здесьzfs receive имеет характер “пульсирующей” нагрузки (bursty) – приняли блок, чего-то делаем и перевариваем, zfs send в это время фактически простаивает (хотя – оба процесса могут давать пропускную способность много больше – просто у одного не забирают, а другой не принимает данные потоком, “забивая” сеть – получается ситуация, когда все компоненты могут существенно больше, чем есть на деле).

Решение – в том же блоге – описано довольно неплохо – надо буферировать приемо-передачу. Для этих целей создана утилита mbuffer. Небольшое клиент-серверное приложение, создающее буфер заданного объема с заданным размером блока внутри.

Успешно собирается (товарищ подтвердит) на Solaris 10, можно и пакеты поставить готовые.

Использование:

# принимаем поток
[root@server2]# mbuffer -s 128k -m 1G -I 9090 | zfs receive datapool/fs1
# отправляем поток
[root@server1]# zfs send datapool/fs1@pipesnap | mbuffer -s 128k -m 1G -O 10.0.0.1:9090

На мой вкус – чистый профит – выигрываем почти 10х приростом производительности!

К сожалению, эти механизмы как-то странно обходят собственно в Solaris 10/11 (по крайней мере – очевидного решения я не нашел).

PS: http://truewaytags.blogspot.com/2011/05/zfs.html – а вот и товарищ по несчастью 🙂