Por que o Ubuntu é lento em uma rede massiva, disco I / O?

Question

Não sei por onde começar neste, mas estou constantemente vendo esse estranho problema no meu Ubuntu Hardy.

O System é o Core i7-920 com discos RAID10 e 3Gb RAM, apesar de que talvez além do ponto. Ele tem vários compartilhamentos do Samba nele. Toda vez que alguém faz upload de algo grande (vários shows) para o compartilhamento, a capacidade de resposta do sistema cai significativamente (notavelmente).

Sistema de arquivos: ReiserFS (v3)

Tanto o vmstat quanto o top não mostram tempo de espera significativo para E / S, muito poucos processos de bloqueio (como 2 para o sistema central 4) e gravações ocasionais de ~ 13000 blocos no disco. Média a carga está constantemente abaixo de 0.5 (novamente o sistema é quad core com HT habilitado, então ele tem 8 núcleos lógicos).

No entanto, mesmo quando eu movo um cursor do mouse, ele fica muito ruim ...

aqui é uma saída vmstat típica durante a E / S de rede de entrada pesada:

vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  0 419268  93724  48052 2071148    0    0     9     3   11    4  1  1 95  2
 1  0 419268  91560  48052 2073292    0    0     0     0 2396 5716  5  1 94  0
 0  0 419268  89636  48056 2075164    0    0     0     0 2173 5537  2  1 97  0
 2  0 419268  87836  48056 2077136    0    0     0     0 2057 5216  1  1 98  0
 1  0 419268  85716  48060 2078812    0    0     0 10104 2108 5261  2  1 97  0
 0  0 419268  91940  48060 2071748    0    0     0     0 2221 6153  2  1 97  0
 2  0 419268  90368  48064 2073640    0    0     0     0 2104 5384  1  1 98  0
 0  0 419268  89000  48064 2075092    0    0     0     0 1781 4700  1  1 98  0
 1  0 419268  87140  48064 2076640    0    0     0     0 2045 5104  1  1 98  0
 1  1 419268  85584  48068 2078240    0    0     0 10112 1945 4343  2  1 91  7
 0  0 419268  92668  48068 2071764    0    0     0    16 2064 5197  2  1 96  1

    

Answer 1

Você pode experimentar os agendadores de I / O. O agendador de IO padrão é CFQ, que funciona muito bem para desktops, mas tem sido minha experiência que, para servidores de arquivos, o Prazo Final tende a funcionar melhor. Você pode alterar o Agendador de IO na hora para experimentar facilmente o que funciona melhor em sua situação.

Para listar os io schedulers disponíveis, use este comando.

cat /sys/block/sdb/queue/scheduler  

Isso deve retornar noop anticipatory deadline [cfq]

Para alterar seu agendador para o prazo, use o seguinte comando no dispositivo apropriado.

sudo echo "deadline" > /sys/block/sdb/queue/scheduler

    

Answer 2

Tente executar iotop - isso deve mostrar alguma coisa.

    

Answer 3

Você vê que muitas interrupções (System-in) e Context Switches (System-cs) durante a operação normal? Eu me pergunto por causa de sua descrição de até mesmo o cursor do mouse se tornando lento. Se houver um problema fazendo com que seu sistema seja sobrecarregado por interrupções sob carga, isso fará tudo ficar lento.

E só para tirar uma foto total no escuro, há alguma coisa em / var / log / dmesg sobre erros ou tempos limite de seus discos ou dispositivos de invasão?

Editar 1:

Eu encontrei um artigo esta manhã que realmente soou como a questão que você está vendo na sua caixa. Greg Smith percorre uma análise de um servidor que parece congelar gravações em disco por longos períodos de tempo. Seu método investigativo particular envolve a execução do comando:

while [ 1 ]; do cat /proc/meminfo; sleep 1; done

e observando o tamanho do cache "Writeback:" antes e durante um período em que o sistema parece travar. Se o cache de write-back estiver de fato preenchido (aproximadamente > 40% cheio) e fazendo com que o sistema suspenda as gravações enquanto é liberado, Greg sugere algum ajuste do sistema operacional que possa atenuar o problema. A entrada do blog de Greg pode ser encontrada no link

    

Answer 4

Não tenho certeza se isso acontece no Linux, mas no Windows Samba as transferências em uma rede de alta velocidade podem superar a velocidade de E / S do disco e como algumas versões anteriores do Windows têm um cache de transferência de rede não inteligente, você pode terminar com um monte muito grande de dados em sua memória em buffers que estão esperando para serem gravados no disco. Isso muitas vezes mata a capacidade de resposta no XP e sistemas anteriores (talvez o Vista, também, IDK eu nunca usei de forma significativa).

    

Answer 5

Eu quero dizer que ReiserFS tem um único bloqueio, e não é realmente adequado para um ataque grande (muitos discos) por esse motivo. Mas tem sido um longo tempo, então eu posso estar errado.

Eu suspeito que mudar o agendador ajudaria bastante.