Клиент NFS имеет несбалансированные скорости чтения и записи
У меня есть NetApp в качестве сервера nfs и два сервера Linux в качестве клиентов nfs. Проблема в том, что на более новом из двух серверов чрезвычайно разные скорости чтения и записи при одновременном чтении и записи на сервер nfs. По отдельности чтение и запись отлично смотрятся на этом новом сервере. На более старом сервере этой проблемы нет.
Старый хозяин: Карп
Sun Fire x4150 с 8 ядрами, 32 ГБ оперативной памяти
SLES 9 с пакетом обновления 4 (SP4)
Сетевой драйвер: e1000
me@carp:~> uname -a
Linux carp 2.6.5-7.308-smp #1 SMP Mon Dec 10 11:36:40 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux
Новый хозяин: Пеппер
HP ProLiant Dl360P Gen8 с 8 ядрами, 64 ГБ ОЗУ
CentOS 6.3
Сетевой драйвер: tg3
me@pepper:~> uname -a
Linux pepper 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Я перейду к некоторым графикам, иллюстрирующим тесты чтения / записи. Вот перец и его несбалансированное чтение / запись:
а вот и карп, молодец:
Тесты
Вот тесты чтения / записи, которые я выполняю. Я запускал их по отдельности, и они отлично смотрятся на перце, но когда они работают вместе (используя &), производительность записи остается стабильной, в то время как производительность чтения сильно страдает. Размер тестового файла вдвое больше оперативной памяти (128 ГБ для перца, 64 ГБ для карпа).
# write
time dd if=/dev/zero of=/mnt/peppershare/testfile bs=65536 count=2100000 &
# read
time dd if=/mnt/peppershare/testfile2 of=/dev/null bs=65536 &
Имя хоста сервера NFS - nfsc. У клиентов Linux есть выделенная сетевая карта в подсети, которая отделена от всего остального (то есть в другой подсети, чем основной IP). Каждый клиент Linux монтирует общий ресурс nfs с сервера nfsc в / mnt / hostnameshare.
nfsiostat
Вот 1-минутный образец во время одновременного чтения / записи перца:
me@pepper:~> nfsiostat 60
nfsc:/vol/pg003 mounted on /mnt/peppershare:
op/s rpc bklog
1742.37 0.00
read: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
49.750 3196.632 64.254 0 (0.0%) 9.304 26.406
write: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
1642.933 105628.395 64.293 0 (0.0%) 3.189 86559.380
У меня еще нет nfsiostat на старом host carpе, но работаю над ним.
/ proc / mounts
me@pepper:~> cat /proc/mounts | grep peppershare
nfsc:/vol/pg003 /mnt/peppershare nfs rw,noatime,nodiratime,vers=3,rsize=65536,wsize=65536,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.x.x,mountvers=3,mountport=4046,mountproto=tcp,local_lock=none,addr=172.x.x.x 0 0
me@carp:~> cat /proc/mounts | grep carpshare
nfsc:/vol/pg008 /mnt/carpshare nfs rw,v3,rsize=32768,wsize=32768,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,timeo=60000,retrans=3,hard,tcp,lock,addr=nfsc 0 0
Настройки сетевой карты
me@pepper:~> sudo ethtool eth3
Settings for eth3:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 4
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: g
Wake-on: g
Current message level: 0x000000ff (255)
Link detected: yes
me@carp:~> sudo ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
Настройки разгрузки:
me@pepper:~> sudo ethtool -k eth3
Offload parameters for eth3:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
me@carp:~> # sudo ethtool -k eth1
Offload parameters for eth1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
Все это в локальной сети с гигабитным коммутатором в полнодуплексном режиме между nfs-клиентами и nfs-сервером. С другой стороны, я вижу, что ЦП ожидает немного большего количества операций ввода-вывода для перца, чем карпа, как и ожидалось, поскольку я подозреваю, что он ожидает операций nfs.
Я захватил пакеты с помощью Wireshark / Ethereal, но я не силен в этой области, поэтому не уверен, что искать. Я не вижу в Wireshark группы пакетов, выделенных красным / черным цветом, так что это все, что я искал :). Эта низкая производительность nfs проявляется в наших средах Postgres.
Есть дополнительные мысли или советы по устранению неполадок? Дайте мне знать, если я могу предоставить дополнительную информацию.
ОБНОВИТЬ
Согласно комментарию @ewwhite, я пробовал два разных профиля tuned-adm, но без изменений.
Справа от моей красной отметки еще два теста. Первый холм с throughput-performance а второй с enterprise-storage.
nfsiostat 60 профиля корпоративного хранилища
nfsc:/vol/pg003 mounted on /mnt/peppershare:
op/s rpc bklog
1758.65 0.00
read: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
51.750 3325.140 64.254 0 (0.0%) 8.645 24.816
write: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms)
1655.183 106416.517 64.293 0 (0.0%) 3.141 159500.441
Обновление 2
Добавление noac Вариант монтирования nfs в fstab был серебряной пулей. Общая пропускная способность не изменилась и по-прежнему составляет около 100 МБ / с, но теперь мои чтение и запись стали намного более сбалансированными, что, как я полагаю, будет хорошим предзнаменованием для Postgres и других приложений.
Как видите, я отметил различные размеры «блоков», которые использовал при тестировании, то есть параметры монтирования размера буфера rsize / wsize. Как ни удивительно, я обнаружил, что размер 8k обеспечивает лучшую пропускную способность для тестов dd.
Это параметры монтирования nfs, которые я сейчас использую, /proc/mounts:
nfsc:/vol/pg003 /mnt/peppershare nfs rw,sync,noatime,nodiratime,vers=3,rsize=8192,wsize=8192,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.x.x,mountvers=3,mountport=4046,mountproto=tcp,local_lock=none,addr=172.x.x.x 0 0
К вашему сведению, noac вариант входа человека:
ac / noac
Выбирает, может ли клиент кэшировать атрибуты файла. Если ни один параметр не указан (или если указан ac), клиент кэширует атрибуты файла.
Для повышения производительности клиенты NFS кэшируют атрибуты файлов. Каждые несколько секунд клиент NFS проверяет серверную версию атрибутов каждого файла на наличие обновлений. Изменения, происходящие на сервере в эти небольшие промежутки времени, остаются незамеченными, пока клиент снова не проверит сервер. Параметр noac запрещает клиентам кэшировать атрибуты файлов, чтобы приложения могли быстрее обнаруживать изменения файлов на сервере.
В дополнение к предотвращению кэширования атрибутов файлов клиентом, опция noac заставляет приложение выполнять записи синхронно, так что локальные изменения в файле сразу становятся видимыми на сервере. Таким образом, другие клиенты могут быстро обнаруживать недавние записи при проверке атрибутов файла.
Использование опции noac обеспечивает большую согласованность кеширования среди клиентов NFS, обращающихся к одним и тем же файлам, но при этом значительно снижает производительность. Поэтому вместо этого рекомендуется разумное использование блокировки файлов. Раздел ДАННЫЕ И СООТВЕТСТВИЕ МЕТАДАННЫХ содержит подробное обсуждение этих компромиссов.
Я читал неоднозначные мнения о кэшировании атрибутов в Интернете, поэтому я думал только о том, что это вариант, который необходим или хорошо работает с сервером NetApp NFS и / или клиентами Linux с более новыми ядрами (> 2.6.5). Мы не наблюдали этой проблемы на SLES 9 с ядром 2.6.5.
Я также читал неоднозначные мнения о rsize / weak, и обычно вы берете значение по умолчанию, которое в настоящее время для моих систем составляет 65536, но 8192 дал мне лучшие результаты тестов. Мы также проведем несколько тестов с postgres, чтобы увидеть, как работают эти различные размеры буфера.