Analisando um servidor lighttpd carregado servindo de NFS

Question

• Contexto:
  • O servidor é uma máquina virtual CentOS 5.2 x86_64 com vmxnet3 ifaces, em execução no VSphere 4.1 em um servidor baseado em Nehalem (que tem metade da CPU e capacidade de memória de acordo com o VCenter) com uma rede de 10 Gb. Quase zero i / o no disco scsi virtual da VM de acordo com iostat.
  • Lê vídeos de um cluster do Isilon usando o NFS (o atime está desativado)
  • Serve-os usando o lighttpd 1.5.0, que fica a 20% da CPU. Cerca de 650 conexões HTTP, incluindo 550 estabelecidas, com uma média de 100 Kb em Send-Q.

Como estamos carregando o servidor com mais pedidos, cpu wait e irq estão aumentando. A memória não é o problema.

Cpu0  :  0.0%us,  3.0%sy,  0.0%ni, 18.0%id,  0.0%wa, 32.0%hi, 47.0%si,  0.0%st
Cpu1  :  3.0%us,  4.0%sy,  0.0%ni, 55.4%id, 34.7%wa,  0.0%hi,  3.0%si,  0.0%st

4163 irq / s na interface usada pelo HTTP e 2269 irq / s na interface do NFS, de acordo com / proc / interrupts. Para respectivamente 180 Mbps e 130 Mbps de acordo com o iptraf.

iostat para o mount do NFS:

rBlk_nor/s   wBlk_nor/s   rBlk_dir/s   wBlk_dir/s   rBlk_svr/s   wBlk_svr/s    rops/s    wops/s
63737.87         0.00         0.00         0.00     61364.71         0.00   1098.04   1107.84

Ei, wops? Mas não setattr e tal em / proc / self / mountstats:

    opts:   ro,vers=3,rsize=32768,wsize=32768,acregmin=1200,acregmax=1200,acdirmin=1200,acdirmax=1200,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys
    age:    2405948
    caps:   caps=0x1,wtmult=8192,dtsize=4096,bsize=0,namelen=255
    sec:    flavor=1,pseudoflavor=1
    events: 3496282 32148506 1 1697 3176945 2598729 37924190 0 33339443 67286271 0 0 20 0 0 0 0 3176406 0 0 0 0 0 0 0
    bytes:  31773968205376 0 0 0 31969360034250 0 7805430344 0
    RPC iostats version: 1.0  p/v: 100003/3 (nfs)
    xprt:   tcp 779 0 50 250 0 1014646219 1014646203 0 8377876491 11916594888
    per-op statistics
            NULL: 0 0 0 0 0 0 0 0
         GETATTR: 3496282 3496282 0 461510280 391583584 2165765 2594488 5332330
         SETATTR: 0 0 0 0 0 0 0 0
          LOOKUP: 2598882 2598882 0 374792176 623714816 3558569 79355750 83640121
          ACCESS: 2824036 2824036 0 384066672 338884320 1788232 2276978 4482334
        READLINK: 0 0 0 0 0 0 0 0
            READ: 1005726981 1005726982 0 144824685416 32098094238420 7454826308 4671373832 13644100410
           WRITE: 0 0 0 0 0 0 0 0
          CREATE: 0 0 0 0 0 0 0 0
           MKDIR: 0 0 0 0 0 0 0 0
         SYMLINK: 0 0 0 0 0 0 0 0
           MKNOD: 0 0 0 0 0 0 0 0
          REMOVE: 0 0 0 0 0 0 0 0
           RMDIR: 0 0 0 0 0 0 0 0
          RENAME: 0 0 0 0 0 0 0 0
            LINK: 0 0 0 0 0 0 0 0
         READDIR: 0 0 0 0 0 0 0 0
     READDIRPLUS: 13 13 0 2132 23788 60 1240 1300
          FSSTAT: 2 2 0 256 336 0 0 0
          FSINFO: 1 1 0 128 164 0 10 10
        PATHCONF: 0 0 0 0 0 0 0 0
          COMMIT: 0 0 0 0 0 0 0 0

• Como saber se o lado HTTP ou o NFS é o problema com o uso do iowait e do irq cpu? Ou como saber se o host do VSphere está atingindo seus limites de E / S?

Answer 1

nodiratime também pode ajudar, mas, eu pensei que relatado sob setattr bem

O cpu0 tem interrupções de hardware / software muito altas e o cpu1 tem tempos de espera razoavelmente altos para 200mb / s, mesmo considerando que o conjunto de dados é maioritariamente frio. Se estes são vídeos longos, o seu rsize pode estar causando fragmentação excessiva se o mtu da eth1 for pequeno. Estou quase pensando que seu tamanho é muito alto. Você pode executar alguns testes de outra estação de trabalho usando dd e várias opções de montagem para ver se o 32768 está impactando negativamente as coisas.

Coloque um ingresso com o Isilon, os técnicos deles também são bons em depurar isso.