Я пытаюсь определить причину плохой производительности nfs между двумя виртуальными машинами Xen (клиент и сервер), работающими на одном хосте. В частности, скорость, с которой я могу последовательно читать файл размером 1 ГБ на клиенте, намного ниже, чем можно было бы ожидать, исходя из измеренной скорости сетевого соединения между двумя виртуальными машинами и измеренной скорости чтения файла непосредственно на сервере. Виртуальные машины работают под управлением Ubuntu 9.04, а сервер использует пакет nfs-kernel-server.
Согласно различным ресурсам настройки NFS, изменение количества потоков nfsd (в моем случае потоков ядра) может повлиять на производительность. Обычно этот совет сформулирован в терминах увеличения числа с 8 по умолчанию на часто используемых серверах. Что я нахожу в своей текущей конфигурации:
RPCNFSDCOUNT=8
: (по умолчанию): 13,5-30 секунд для загрузки файла размером 1 ГБ на клиенте, то есть 35-80 МБ / с
RPCNFSDCOUNT=16
: 18 с для катания файла 60 МБ / с
RPCNFSDCOUNT=1
: 8-9 секунд катить файл (!!?!) 125МБ / с
RPCNFSDCOUNT=2
: 87 с для катания файла 12 МБ / с
Я должен упомянуть, что файл, который я экспортирую, находится на твердотельном накопителе RevoDrive, установленном на сервере с использованием сквозной передачи PCI Xen; на сервере я могу скопировать файл менее чем за секунды (> 250 МБ / с). Я сбрасываю кеши на клиенте перед каждым тестом.
Я действительно не хочу оставлять сервер настроенным только с одним потоком, поскольку я предполагаю, что это не будет работать так хорошо, когда есть несколько клиентов, но я могу неправильно понять, как это работает. Я повторил тесты несколько раз (меняя конфигурацию сервера между ними), и результаты довольно стабильны. Итак, мой вопрос: почему лучшая производительность с 1 потоком?
Еще несколько вещей, которые я попытался изменить, но практически безрезультатно:
увеличение значений / proc / sys / net / ipv4 / ipfrag_low_thresh и / proc / sys / net / ipv4 / ipfrag_high_thresh до 512K, 1M по умолчанию 192K, 256K
увеличение значения / proc / sys / net / core / rmem_default и / proc / sys / net / core / rmem_max до 1M со значения по умолчанию 128K
установка с опциями клиента rsize = 32768, wsize = 32768
Из вывода sar -d я понимаю, что фактические размеры чтения, поступающие на базовое устройство, довольно малы (<100 байт), но это не вызывает проблем при чтении файла локально на клиенте.
RevoDrive фактически предоставляет два устройства «SATA»: / dev / sda и / dev / sdb, затем dmraid подбирает полосатый по ним поддельныйRAID-0, который я смонтировал в / mnt / ssd, а затем привязал к / export / ssd. Я провел локальные тесты своего файла, используя оба местоположения, и увидел упомянутую выше хорошую производительность. Если ответы / комментарии потребуют подробностей, я их добавлю.
Когда приходит клиентский запрос, он передается одному из потоков, а остальные потоки просят выполнить операции упреждающего чтения. Самый быстрый способ прочитать файл - сделать это последовательно одним потоком ... Так что для одного файла это перебор, и потоки, по сути, делают больше работы для себя. Но то, что верно для 1 клиента, читающего 1 файл, не обязательно будет правдой при развертывании в реальном мире, поэтому придерживайтесь формулы для определения количества потоков и количества упреждающих операций чтения на основе характеристик полосы пропускания / ЦП.