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.
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:
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?
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.
Tags performance ssd io kali-linux