LINUX.ORG.RU
решено ФорумAdmin

qemu-kvm+nfs=тормоза

 , , ,


0

3

Добрый ночер, господа. Есть сервер с debian

root@srv:# uname -a
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1 x86_64 GNU/Linux

Запущен nfs-сервер

root@srv:~# nfsstat
Server rpc stats:
calls      badcalls   badclnt    badauth    xdrcall
324311886   0          0          0          0

Server nfs v3:
null         getattr      setattr      lookup       access       readlink
14        0% 266007668 82% 4356800   1% 9342142   2% 11248602  3% 7695      0%
read         write        create       mkdir        symlink      mknod
12223959  3% 11811445  3% 2587082   0% 12663     0% 5365      0% 0         0%
remove       rmdir        rename       link         readdir      readdirplus
1983956   0% 6300      0% 1417518   0% 2602      0% 0         0% 1349058   0%
fsstat       fsinfo       pathconf     commit
1362331   0% 1746      0% 870       0% 30280     0%

Поднята виртуалка на qemu-kvm Сеть сконфирурирована через tap и brctl

kvm -smp 12 -m 120000 -vga std -vnc :2 -boot c -cdrom debian-7.8.0-amd64-netinst.iso -drive if=virtio,file=debian_nfs.qcow2 -drive if=virtio,file=/dev/sdc -net nic,macaddr=DE:AD:BE:EF:76:93,model=virtio -net tap,ifname=tap0,script=no,downscript=no

(пакеты ходят vm1-eth0---srv-tap0---srv-br0)

У виртуалки nfs-root через virtio-интерфейс

user@vm:# mount | grep nfs
x.x.x.x:/srv/kvm_mount1 on / type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,port=2049,timeo=7,retrans=10,sec=sys,local_lock=all,addr=x.x.x.x)

При копировании мелких файлов на nfs-шару (например разжатие гзипника с кучей файлов внутри) начинается адЪ:

user@vm1:#  nfsiostat -hk 20
Filesystem:               rkB_nor/s    wkB_nor/s    rkB_dir/s    wkB_dir/s    rkB_svr/s    wkB_svr/s     ops/s    rops/s    wops/s
x.x.x.x:/srv/kvm_mount1
                               0.00        56.81         0.00         0.00         0.00        56.96     50.70      0.00      8.20

root@srv:# iostat -kx 20
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.48    0.00    0.10    5.88    0.00   87.53

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00    71.05    0.00   71.40     0.00   575.00    16.11     0.95   13.34    0.00   13.34  13.33  95.20

Скорость при этом вообще никакая, по сети через ftp быстрее было бы На vm1 при этом iowait на одном из ядер около 50% Если погонять iperf между srv и vm1, то скорость от виртуалки к серверу где-то 200М, при этом si-time иногда кратковременно подскакивает на одном из ядер виртуалки до 100%, но потом возвращается на 30-50%. Скорость от внешних машин к виртуалке при этом, что характерно, где-то 500М

Если шару перетащить на ssd - жизнь становится значительно лучше, но кажется мне, что я как-то неправильно готовлю nfs-сервер, если для того, чтобы получить производительность обычного жёсткого диска надо ставить ssd, из-за того, что диск загибается под кучей коротких random writes.

Конфиг nfs на srv дефолтный:

root@srv:~# cat /etc/default/nfs-kernel-server
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids"
NEED_SVCGSSD=
RPCSVCGSSDOPTS=

root@srv:~# grep -v  «^#» /etc/default/nfs-common
NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=

root@srv:#cat /etc/exports
/srv/kvm_mount1/ x.x.x.x/x(rw,sync,fsid=0,crossmnt,no_subtree_check,no_root_squash)

Традиционный вопрос - куда копать, что проверять. HOWTO по оптимизации NFS курил, особенно полезного ничего не нашёл (ну или тупой и не понял, что оно полезное). Из идей - сделать async шару, и надеяться, что сервер никогда не упадёт. Но как-то стрёмно. Или все настоящие джедаи так всегда делают?

exports

async

anonymous
()
Ответ на: комментарий от blind_oracle

Ага, понятно. А как при этом подкрутить настройки, чтобы у меня операции записи не висели в кэше по два часа?

Памяти на сервере много, нагрузка на IO не всегда большая. Совать в крон sync каждые 10 минут - порнография.

Или так не бывает и там какие-то барьеры автоматически сделаны?

sometyx
() автор топика
Ответ на: комментарий от darkenshvein

Приведённая статистика для случая, когда кроме qemu никто IO нагрузки не создаёт. Почему планировщик должен влиять?

sometyx
() автор топика
Ответ на: комментарий от sometyx

Совать в крон sync каждые 10 минут - порнография.

Система сама сбрасывает на диск. Если не путаю интервал около секунды.

itn ★★★
()
Ответ на: комментарий от darkenshvein

Э... wut?

планировщик io какой? поставь цфкью, поставь приоритет класс приоритета къему пониже.

Из этой фразы следует, что планировщик может влиять. Поскольку мне это неочевидно, я таки переспросил. Класс приоритета qemu тоже неочевидно что влияет - у системы нет другой IO нагрузки.

Или это я чего-то не понимаю?

Да,

cat /sys/block/sda/queue/scheduler
noop deadline [cfq]

sometyx
() автор топика
Ответ на: комментарий от sometyx

ну. я предположил, что наступает затык по железу и всё дико тормозит. Тогда поможет понижение приоритета для того процесса, что дрючит диск.

darkenshvein ★★★★★
()
Ответ на: комментарий от sometyx

Там всё уже продумано за тебя :) Если ФС на нфс сервере журналируемая, а других нонче нет, то ничего страшного не случится при неожиданном разрыве связи или еще катаклизме.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Понял, спасибо! Переставил на async, посмотрю что получится.

sometyx
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.