Emitir

Question

Emitir

Instalei recentemente o Ubuntu 16.04 LTS (kernel 4.8.0-52) em um Lenovo T460p com um i7-6820HQ, 32 GB de RAM e um SSD Micron 1100 de 512 GB. Marquei 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 demorar cerca de duas vezes mais. Além disso, durante partes da compilação que gravam arquivos grandes, qualquer tarefa (não relacionada à compilação) que exija E/S de disco acaba esperando muito. Isso inclui lançar novos programas, carregar páginas no Firefox, etc. No Firefox, por exemplo, posso navegar na interface do usuário, alternar guias e está tudo bem. Mas se eu seguir um link, toda a IU será bloqueada até que as coisas se acalmem.

Então, em resumo, depois de algum tempo, as compilações de repente demoram mais e em certos pontos durante a construção o computador fica basicamente inutilizável.

O que posso fazer para tentar diagnosticar ou resolver esse problema?

Informações sobre solução de problemas

• Não reinicie com frequência, para que o sistema fique ativo por vários dias antes de eu me deparar com esse problema. Assim que acertei, me agito um pouco tentando descobrir o problema e, em seguida, reinicio para poder continuar trabalhando.

• A única coisa que resolve o problema é reiniciar a máquina. Eu tentei sair de todos os aplicativos, fazer logout e login novamente e descartar o cache do buffer (teoria do fracasso de que, como ele usava o espaço de memória, as sincronizações do disco estavam acontecendo com mais frequência), mas apenas a reinicialização funciona.

• Como um tiro no escuro, tentei a solução paraesta respostamas não houve mudança de comportamento.

• A execução iotopmostra o dmcrypt_writethread usando 99% de E/S sempre que estou enfrentando problemas. Quando estounãoenfrentando o problema, também vejo dmcrypt_writepop no topo com um IO% relativamente alto, mas não permanece lá por muito tempo.

• Se eu executar dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; syncquando as coisas estiverem funcionando normalmente, dmcrypt_writesaltarei para o topo por um ou dois segundos, mas não terá a mesma duração de uma de 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 pequenos arquivos são criados, além de alguns arquivos JAR maiores que agregam todos esses pequenos arquivos.

• Sempre há bastante memória disponível e a partição swap não está sendo usada.

• Tenho colegas de trabalho com computadores semelhantes (T460p) que também executam o Ubuntu e que não estão enfrentando esse problema. Todos eles parecem terdiferenteMarca/modelos de SSD, no entanto.

Atualizar

O problema surgiu novamente, então fiz mais alguns testes com base na resposta a esta pergunta.

• O sistema de arquivos ainda não está montado com a discardopção, então corri fstrimassumindo que seria algo semelhante a ter a discardopção habilitada
• Não fiz o tempo suficiente quando o problema aconteceu pela primeira vez, mas depois de executar fstrim, as velocidades de construção pareciam ter voltado ao normal...masapós a conclusão da compilação, o dmcrypt_writethread entra em ação e torna o sistema inutilizável por um período de tempo. Todo e qualquer tempo total para construir e para o sistema se tornar utilizável parece ser praticamente o mesmo de antes.
• Mudei /proc/sys/vm/dirty_ratiopara 2 e /proc/sys/vm/dirty_background_ratio1 e executei algumas compilações. As compilações demoraram mais do que o normal – quase o mesmo que da última vez que encontrei esse problema, mas o sistema não pareceu travar tanto. Alterá-lo de volta para 20 e 10 reverteu o comportamento mencionado acima.
• Em uma inicialização limpa, tentei definir /proc/sys/vm/dirty_ratiopara 2 e /proc/sys/vm/dirty_background_ratio1 e o tempo foi comparável a 20 e 10.

Answer 1

Eu tive um problema semelhante no Debian 10+11 onde, se eu fizesse grandes operações de gravação no disco LUKS, todo o meu sistema congelaria por algum tempo, depois responderia novamente e depois congelaria novamente...

Porém, não precisei reiniciar - apenas espere até que a operação de gravação fosse concluída.

Como ScumCoder escreveu, há uma correção disponível. A partir do kernel 5.9 a correção está integrada ao kernel.

O seguinte comando corrigiu isso para mim:

cryptsetup --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh nvme0n1p3_crypt

Extraí meu nome de disco "nvme0n1p3_crypt" usando o comandodmsetup table

Eu me inspirei emhttps://wiki.archlinux.org/title/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance

Após a correção, minhas operações de escrita são muito mais rápidas.

Answer 2

Tenho exatamente o mesmo problema que você, e uma pesquisa rápida mostrou este post:

https://blog.cloudflare.com/speeding-up-linux-disk-encryption

O funcionário da CloudFlare pesquisou bastante o código-fonte do Linux e concluiu que o culpado é a dmcryptimplementação atual. Ele resolveu o problema basicamente reescrevendo a parte correspondente do kernel.

Portanto, no AFAIK, as únicas duas maneiras de se livrar da lentidão são (1) compilar sua versão do kernel ou (2) reiniciar de vez em quando (como você disse). Eu escolhi o último.

Answer 3

Não sei especificamente sobre o LUKS, mas para problemas gerais de IO em um SSD, certifique-se de que o descarte esteja ativado para sua montagem fs, ou seja, grep descarta /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 IO mais cedo, quando houver menos registros atrasados ​​de dados para gravar.