У меня есть сервер CentOS 5 VMWare, подключенный к машине OpenSolaris 2009.06 через NFS, на которой хранятся образы дисков. Кажется, что мои виртуальные машины связаны медленным вводом-выводом, поэтому я хотел бы сделать все возможное, чтобы оптимизировать соединение.
Я не уверен, как лучше всего измерить пропускную способность производственной системы, но некоторые ненаучные тесты с использованием dd bs=1024k count=400 show local (OpenSolaris) записывает ~ 1,6 ГБ / с, а удаленный (CentOS) записывает ~ 50 МБ / с. Я полагаю, это ниже, чем я получаю на самом деле, поскольку в настоящее время через соединение работает 7 виртуальных машин.
В настоящее время 2 машины имеют прямое соединение gigE с включенными jumbo-кадрами на обоих сетевых адаптерах (MTU = 9000). Кроме этого, никаких оптимизаций не производилось. При монтировании / экспорте NFS используются значения по умолчанию.
Где мне начать вращать ручки, чтобы улучшить производительность?
Чтобы уточнить, вы получаете 50 МБ / с с NFS через подключение к Ethernet на один гигабайт?
А хост-сервер работает под управлением CentOS с установленным сервером VMware, который, в свою очередь, запускает 7 виртуальных машин? Есть ли какая-то конкретная причина, по которой вы выбрали сочетание CentOS и VMware Server, а не VMware ESXi, которое является более производительным решением?
50 МБ / с - это не очень хорошо, но это ненамного ниже того, что вы ожидаете от сетевого кабеля с одним Гбит / с - как только вы добавите настройки NFS, упомянутые выше, вы увидите, может быть, 70- 80 МБ / сек. Варианты по линии:
"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"
вероятно, разумны для вас на обоих концах системы.
Чтобы добиться этого, вам нужно будет объединить сетевые карты в пары, что должно увеличить пропускную способность примерно на 90%. Вам может понадобиться коммутатор, поддерживающий 802.3ad, чтобы получить максимальную производительность с агрегирование ссылок.
Одна вещь, которую я предлагаю, заключается в том, что ваша пропускная способность ввода-вывода в системе OpenSolaris кажется подозрительно высокой, 12 дисков вряд ли будут поддерживать пропускную способность 1,6 ГБ / с, и это может быть сильно кэшировано Solaris + ZFS.
Попробуйте следующее: временно отключите журнал намерений ZFS (ZIL) на сервере OpenSolaris NFS, выполнив следующие два действия.
echo zil_disable/W0t1 | mdb -kwЗатем проверьте еще раз. Ты можешь использовать зилстат чтобы убедиться, что ввода-вывода на ЗИЛ действительно больше нет. Если тест проходит быстрее, значит, проблема с производительностью как-то связана с ЗИЛом. Если он по-прежнему работает медленно, вы знаете, что ЗИЛ не виноват, и что использование SSD для ЗИЛ также не поможет. Увидеть Руководство по настройке ZFS Evil для получения дополнительной информации о ЗИЛе.
Другой вариант - захватить сетевой трафик (например, с помощью Wireshark) и посмотреть, есть ли проблемы, например. с Jumbo-кадрами. Убедитесь, что пакеты в проводе выглядят так, как вы ожидаете от вашей конфигурации. Происходит ли плохая фрагментация? Есть ретрансляции?
Однажды я провел тест с dell r710, 1 процессором, 4 ГБ ОЗУ, 6 дисками SATA с RAID-10. Клиент был sun x2100, как с CentOS 5.3, так и с параметрами nfs, как указано выше.
"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"
установлен с обеих сторон с нотами.
Я также увеличил nfsds до 256 и использовал планировщик noop для raid-контроллера perc6. Еще я выровнял разделы по размеру полосы 64 КБ рейд-контроллера.
затем я измерил производительность nfs с помощью dd - для чтения я мог заполнить канал gigE, но для записи я мог получить только немного лучшие результаты, чем вы. С включенным асинхронным режимом я мог получить от 70 до 80 МБ / с, но асинхронный режим для моего.
Может, с nfs больше не получишь по ссылке gigE?
Для наших машин RHEL / CentOS 5 мы используем следующие флаги монтирования
nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, hard, intr, noatime
Более новая версия ядра Linux поддерживает даже большие параметры rsize / wsize, но 32k - это максимум для ядра 2.6.18 в EL5.
На сервере (ах) NFS, по крайней мере, для Linux предположительно no_wdelay помогает, если у вас есть контроллер диска с BBWC. Кроме того, если вы используете флаг noatime на клиентах, вероятно, имеет смысл смонтировать файловые системы на серверах с noatime.
И, как уже было сказано, не беспокойтесь об UDP. В более высокоскоростных сетях (1GbE +) существует небольшая, но отличная от нуля вероятность того, что перебор порядкового номера приведет к повреждению данных. Кроме того, если есть вероятность потери пакета, TCP будет работать лучше, чем UDP.
Если вас не так сильно беспокоит целостность данных, вариант экспорта «асинхронный» может значительно улучшить производительность (проблема с асинхронным режимом в том, что вы можете потерять данные в случае сбоя сервера).
Кроме того, по крайней мере для сервера Linux, вам необходимо убедиться, что у вас достаточно запущенных потоков сервера NFS. Значение по умолчанию 8 слишком мало.
Может помочь увеличение размеров полезной нагрузки чтения и записи. Особенно в сочетании с jumbo-кадрами.
Я считаю оптимальным 32k.
rsize=32768,wsize=32768
Переключение на транспорт UDP, конечно, происходит быстрее, чем TCP, потому что это экономит накладные расходы на управление передачей. Но это применимо только в надежных сетях и где NFSv4 не используется.
Производительность NFS в ZFS значительно улучшается за счет использования SSD для журнала намерений ZFS (ZIL), поскольку это снижает задержку операций. Эта ветка о VMWare NFS на производительности ZFS в списках рассылки OpenSolaris NFS и ZFS есть дополнительная информация, в том числе инструмент тестирования производительности, чтобы увидеть, является ли производительность ZIL узким местом.
К вашему сведению, команда dd будет записывать в кеш, а не на диск, вы можете получить сумасшедшие цифры, такие как 1,6 Гб / с, потому что вы пишете в ОЗУ, а не на диск на Solaris, вы можете использовать "-oflag = sync" для принудительной записи на диск