Eu instalei recentemente o Ubuntu 16.04 LTS (kernel 4.8.0-52) em um Lenovo T460p com um i7-6820HQ, 32GB de RAM e um SSD Micron 1100 de 512GB. Eu verifiquei a caixa de criptografia completa do disco durante a instalação e usei o layout de particionamento padrão. Em geral, o desempenho é ótimo.
No entanto , com o tempo, minhas compilações começaram a ser executadas, levando o dobro do tempo. Além disso, durante partes da compilação que gravam arquivos grandes, qualquer tarefa (não compilada) que exija E / S de disco acaba esperando muito. Isso inclui o lançamento de novos programas, o carregamento de páginas no Firefox, etc. No Firefox, por exemplo, posso navegar na interface do usuário, alternar as guias e está tudo bem. Mas se eu seguir um link, toda a interface do usuário trava até que as coisas se acalmem.
Então, em resumo, depois de algum período de tempo, os builds de repente demoram mais e, em certos pontos, durante a compilação, o computador fica basicamente inutilizável.
O que posso fazer para tentar diagnosticar ou resolver este problema?
Não reinicialize frequentemente, por isso o sistema fica com vários dias de atraso até eu me deparar com esse problema. Uma vez que eu bati, eu me atrapalhei um pouco tentando descobrir o problema, então reiniciei para que eu possa continuar trabalhando.
A única coisa que resolve o problema é reinicializar a máquina. Eu tentei sair todos os aplicativos, sair e voltar, e soltando o cache de buffer (teoria de flail que, como ele usava sincronizações de disco de espaço de memória estavam acontecendo com mais freqüência), mas apenas a reinicialização funciona.
Como um plano, tentei a solução para esta resposta mas não houve mudança de comportamento.
A execução de iotop mostra o encadeamento dmcrypt_write usando 99% de E / S sempre que estou com problemas. Quando não estou com o problema, também vejo dmcrypt_write pop no topo com um% IO relativamente elevado, mas não fica muito tempo aqui.
Se eu executar dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; sync quando as coisas estiverem funcionando normalmente, dmcrypt_write irá pular para o topo por um segundo ou dois, mas não está perto da mesma duração de uma das minhas compilações.
Uma compilação completa gera cerca de 1,4 GB de dados. É um projeto Java com vários módulos. Assim, muitos arquivos pequenos são criados, além de alguns arquivos JAR maiores que agregam todos esses pequenos arquivos.
Há sempre muita memória disponível e a partição de troca não está sendo usada.
Eu tenho colegas de trabalho com computadores semelhantes (T460p) também executando o Ubuntu que não estão enfrentando esse problema. Eles todos parecem ter marcas / modelos diferentes de SSD.
O problema surgiu novamente, então fiz mais alguns testes com base na resposta a essa pergunta.
discard , então, em vez disso, executei fstrim supondo que seria algo semelhante a ter a opção discard ativada fstrim , as velocidades de compilação pareciam estar de volta ao normal ... mas após a conclusão da compilação, o dmcrypt_write thread entra em ação e torna o sistema inutilizável por um período de tempo. Todo e todo o tempo total para construir e para o sistema se tornar utilizável parece ser o mesmo de antes. /proc/sys/vm/dirty_ratio para 2 e /proc/sys/vm/dirty_background_ratio para 1 e executei algumas construções. As compilações levaram mais tempo do que o normal - quase o mesmo que da última vez que eu acertei esse problema, mas o sistema não pareceu travar tanto. Mudando de volta para 20 e 10 voltou ao comportamento mencionado acima. /proc/sys/vm/dirty_ratio para 2 e /proc/sys/vm/dirty_background_ratio para 1 e o tempo era comparável a 20 e 10. Não sei especificamente sobre LUKS, mas para problemas gerais de IO em um SSD, certifique-se de que o descarte está ativo para sua montagem fs, por exemplo, grep descard / proc / mounts também pode tentar (como root) "echo 1 > > / proc / sys / vm / dirty_background_ratio; echo 2 > > / proc / sys / vm / dirty_ratio ", isso fará com que o sistema inicie o E / S antes, quando houver menos um registro de dados a ser gravado.