Como lidar com o bloqueio de E / S reduzindo o desempenho a um rastreamento?

1

Eu tenho um computador que está passando por alguns problemas graves de E / S.

Software: Kali-rolando, Linux x86-desktop-1 4.12.0-kali2-amd64 # 1 SMP Debian 4.12.13-1kali2 (2017-10-03) x86_64 GNU / Linux. Mas eu tive vários kernels, stocks e customizados.

Hardware: O hardware relevante é o seguinte. CPU Ryzen 1800X, 16 GiB de RAM, MSI X370 SLI PLUS com o BIOS mais recente (versão 3.6, mas eu também tentei outros três), M.2: SSD Crucial® MX300 525GB M.2 e SSD 840 PRO de 256 GB.

O problema: o problema talvez possa ser melhor descrito apenas da perspectiva do usuário no início:

Estou copiando muitos arquivos pequenos, como a árvore de código-fonte do kernel do Linux. Isso resulta em muita lentidão, que até mesmo um comando simples como o binário "ls" ou "dmesg" pode levar 15 segundos ou mais para ser executado. O sistema inteiro congela em termos de E / S, qualquer coisa que requeira qualquer forma de E / S será bloqueada até que o que estiver bloqueando permita que ela passe pela fila de E / S.

Eu notei o problema ao fazer o seguinte:

  • Reproduzindo um arquivo de vídeo pela rede, a partir de um recurso CIFS. Essa forma de E / S pode introduzir um segundo ou dois atrasos no fluxo de vídeo.
  • A reprodução de um arquivo MP3 pela rede, durante o uso de um navegador da Web, pode causar o travamento do áudio.
  • Copiando algo localmente no dispositivo SSD ou M.2, talvez especialmente quando envolve muitos arquivos pequenos.

O problema começou desde que eu instalei o sistema operacional e sempre esteve lá.

Meu raciocínio e como tentei resolver isso: o hardware deve ser mais do que capaz de lidar com várias solicitações de E / S ao mesmo tempo. A idéia de que isso seria causado por um SSD / M.2 defeituoso não parece razoável, já que eu tentei tanto um SSD quanto um dispositivo M.2 fisicamente separado, ambos têm o mesmo problema. Além disso, também parece não ser razoável que o kernel kali tenha esse problema específico de I / O, especialmente desde que eu tentei múltiplos kernels: 4.9, 4.12, 4.13.2, 4.13.10. Considerei que talvez existam opções de BIOS que afetariam esse desempenho, mas não consegui encontrar nada, independentemente de estar executando os padrões de configuração e de ter tentado várias versões de BIOS, incluindo as versões 3.4, 3.5 e 3.6.

Eu verifiquei o dmesg em busca de erros de E / S, não há nenhum.

Eu também considerei que existem vários agendadores de E / S para o Linux:

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

O agendador pode ser alterado emitindo, por exemplo,

echo "noop" > /sys/block/sda/queue/scheduler

Veja esta pergunta para obter mais informações: link

No entanto, eu tentei noop, prazo e CFQ, eles não parecem afetar o problema em tudo.

Também queria verificar o desempenho dos dispositivos não voláteis:

hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 1112 MB in  3.01 seconds = 369.69 MB/sec
hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 1122 MB in  3.00 seconds = 373.53 MB/sec

O desempenho não é nada impressionante, eu deveria ter mais do que isso. Mas mesmo com esse tipo de desempenho, esses problemas devem ser inexistentes. Não tenho certeza se o problema que estou tendo está relacionado a esse desempenho de E / S ruim.

Quando eu estava rodando o Gentoo neste mesmo sistema, eu consegui isso no dispositivo 840 PRO ( hdparm -t ):

510.82 MB/sec
524.05 MB/sec

Como devo proceder para depurar este problema? É óbvio para alguém qual é o problema?

    
por AlphaCentauri 02.12.2017 / 15:53

1 resposta

0

Ele não explica o que está acontecendo, mas você pode tentar contornar o problema usando ionice para operações de unidade e tc (modelagem de tráfego) para operações de rede.

    
por 03.12.2017 / 19:02