Eu colocaria a culpa na velha versão xen usada no seu host (CentOS 5.5). Posso realmente recomendar o uso do SLES 10 ou 11. 11 possui XEN 4.x embutido.
Não tenho problemas de desempenho com meus DomOS do CentOS 5 em execução no SLES 10 Dom0s.
Estou tendo sérios problemas com um servidor baseado em xen, isso está na partição guest. É um CentOS 5.5 paravirtualizado. Não tenho certeza se é relacionado a hardware ou software ou entre (drivers).
Informações básicas
Atualizado firmware do controlador (isso foi feito como último passo)
Smart Array 6i in Slot 0
Hardware Revision: Rev B
Firmware Version: 2.84
kernel atualizado
Linux domU 2.6.18-194.32.1.el5xen #1 SMP Wed Jan 5 19:32:33 EST 2011 i686 i686 i386 GNU/Linux
O problema está na velocidade de gravação em disco.
O desempenho da linha de base é
Os números a seguir são tirados da parte superior enquanto copia um arquivo grande pela rede.
Se eu copiar o arquivo outra vez, a velocidade diminuirá em relação à média de carregamento. Então a segunda vez é metade da velocidade da primeira vez.
Precisa de algum tempo para se refrescar depois disso. A média de carga diminui lentamente até que seja mais uma vez utilizável. ls / demora cerca de 30 segundos.
top - 13:26:44 up 13 days, 21:44, 2 users, load average: 7.03, 5.08, 3.15
Tasks: 134 total, 2 running, 132 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.1%sy, 0.0%ni, 25.3%id, 74.5%wa, 0.0%hi, 0.0%si, 0.1%st
Mem: 1048752k total, 1041460k used, 7292k free, 3116k buffers
Swap: 2129912k total, 40k used, 2129872k free, 904740k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1506 root 10 -5 0 0 0 S 0.3 0.0 0:03.94 cifsd
1 root 15 0 2172 644 556 S 0.0 0.1 0:00.08 init
Enquanto isso, o host é ~ 0,5 load avg e steady com o tempo. ~ 50% de espera
O hardware do servidor é dual xeon, 3gb ram, 170gb scsi 320 10k rpm e não deve ter problemas com a cópia de arquivos pela rede.
disk = [ "tap:aio:/vm/domU.img,xvda,w" ]
Eu também os recebo no log
INFO: task syslogd:1350 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syslogd D 00062E4F 2208 1350 1 1353 1312 (NOTLB)
c0ef0ed0 00000286 6e71a411 00062e4f c0ef0f18 00000009 c0f20000 6e738bfd
00062e4f 0001e7ec c0f2010c c181a724 c1abd200 00000000 ffffffff c0ef0ecc
c041a180 00000000 c0ef0ed8 c03d6a50 00000000 00000000 c03d6a00 00000000
Call Trace:
[<c041a180>] __wake_up+0x2a/0x3d
[<ee06a1ea>] log_wait_commit+0x80/0xc7 [jbd]
[<c043128b>] autoremove_wake_function+0x0/0x2d
[<ee065661>] journal_stop+0x195/0x1ba [jbd]
[<c0490a32>] __writeback_single_inode+0x1a3/0x2af
[<c04568ea>] do_writepages+0x2b/0x32
[<c045239b>] __filemap_fdatawrite_range+0x66/0x72
[<c04910ce>] sync_inode+0x19/0x24
[<ee09b007>] ext3_sync_file+0xaf/0xc4 [ext3]
[<c047426f>] do_fsync+0x41/0x83
[<c04742ce>] __do_fsync+0x1d/0x2b
[<c0405413>] syscall_call+0x7/0xb
=======================
Eu tentei desabilitar o irqbalanced como sugerido aqui mas isso não parece fazer qualquer diferença.
Atualizações:
domU# cat /sys/block/xvda/queue/scheduler
[noop] anticipatory deadline cfq
Copiar arquivos de / para o disco faz com que a carga permaneça < 4. A cópia subseqüente faz com que a carga aumente. Copiar arquivos pela rede causa carga > 4 na primeira execução, a cópia subsequente faz com que o servidor pare quase completamente, exigindo tempo para esfriar, ele nunca desce, apenas 10-15 minutos para voltar. Mas realmente não é viável para um servidor se comportar assim.
O tráfego de rede, por si só, não causa nenhum problema ao executar o iperf, por exemplo, não produz nenhum efeito mensurável. A largura de banda reportada é > 1gbit.
O desempenho de gravação no dom0 é OK
dom0# dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 34.9725 seconds, 30.7 MB/s
O desempenho de gravação no domU é lento
domU# dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 622.163 seconds, 1.7 MB/s
Isso representa uma perda de desempenho de ~ 95%.
O desempenho de leitura está OK
dom0# hdparm -tT /dev/cciss/c0d0p1
/dev/cciss/c0d0p1:
Timing cached reads: 3352 MB in 2.00 seconds = 1676.70 MB/sec
Timing buffered disk reads: 100 MB in 2.59 seconds = 38.57 MB/sec
domU# hdparm -tT /dev/xvda
/dev/xvda:
Timing cached reads: 3144 MB in 2.00 seconds = 1571.51 MB/sec
Timing buffered disk reads: 120 MB in 3.03 seconds = 39.67 MB/sec
Atualização:
Então, parece que isso era relacionado a hardware, afinal. Mas não apareceu até executar xen. A bateria não estava carregando ok, isso levou ao cache sendo desativado. Isso em combinação com uma VM que executa IO intensivo levou a altos tempos de espera.
Agora, imediatamente após a atualização do firmware, nada mudou, mas desde a atualização do firmware, a bateria está agora carregando corretamente. E depois que a bateria está totalmente carregada, as velocidades de gravação agora são aceitáveis, pois arquivos pequenos excedem os de dom0, sem nenhuma pista de por que isso acontece.
domU# dd if=/dev/zero of=./test1024M bs=1024k count=1024 conv=fsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 39.1087 seconds, 27.5 MB/s
Tags virtualization xen centos blocking