A atividade de gravação pesada no SSD atua no desempenho do sistema

Question

Tenho notado que, quando faço aplicativos pesados de gravação, todo o sistema fica mais lento. Para testar isso, executei isso para fazer uma atividade de disco alta (relativamente) baixa de CPU:

john -incremental > file_on_SSD

Isso bombeia dezenas de milhares de strings por segundo para um arquivo no disco do meu sistema.

Quando está fazendo isso, o mouse fica atrasado, os TTYs não respondem, os aplicativos "desaparecem" e, geralmente, todo o computador fica inutilizável. Quando eu puder controlar Control + C john , o sistema volta à força total após alguns segundos.

Este é um exemplo extremo, mas tenho problemas semelhantes com atividades um pouco menos intensivas em gravação, como copiar arquivos grandes de fontes rápidas ou transcodificação.

Meu disco principal do sistema operacional é um SSD bastante rápido ( OCZ Agility 60GB ) com o EXT4. Se eu gravar a saída de john em um disco mecânico com EXT4, não sofrerei as mesmas lentidões, embora a taxa seja muito mais lenta (o SSD tem ~ 42.000 palavras por segundo, o mecânico faz 8.000 w / s). O rendimento pode ser relevante. O disco mecânico também não tem nada a ver com o sistema. São apenas dados.

E estou usando o kernel 2.6.35-2, mas notei esse problema desde que recebi este SSD quando provavelmente estava usando o .31 ou algo desse tempo.

Então, o que está causando a desaceleração? Questão EXT4? Questão do kernel? Questão SSD? Tudo acima? Algo mais?

Se você acha que eu preciso fazer um teste adicional, apenas deixe um comentário me dizendo o que fazer e eu adicionarei o resultado à pergunta.

    

Answer 1

Este foi um problema conhecido por algum tempo. Usar um FS sintonizado por SSD como o Btrfs pode ajudar, mas talvez não.

Por fim, é um bug nos sistemas de gerenciamento de agendamento / memória IO. Recentemente, houve alguns patches que visam resolver esse problema. Veja Corrigido: o problema de capacidade de resposta do desktop Linux?

Estes patches podem eventualmente entrar no kernel da linha principal, mas por enquanto, você provavelmente terá que compilar seu próprio kernel se quiser corrigir este problema.

    

Answer 2

Existem algumas coisas que você pode verificar para tentar melhorar o desempenho do SSD no Linux.

1. Defina o ponto de montagem como 'noatime'. A atividade extra de atualização dos tempos de acesso geralmente é desperdiçada na maioria dos casos de uso. Especialmente no caso de bombear continuamente linhas únicas para um arquivo, você está forçando várias atualizações no sistema de arquivos para cada acesso.

2. Verifique o elevador. O elevador padrão para a maioria das distros é configurado para pratos giratórios de acesso aleatório. Os SSDs não precisam da lógica extra, portanto, configurar o elevador para noop pode melhorar o desempenho, permitindo que o hardware gerencie as gravações.

3. Armazenamento em cache por write-back v write-back. Isso é um pouco mais esotérico, mas você pode verificar o método de cache usado com hdparm para o dispositivo. O cache de write-back pode ter um impacto positivo no desempenho do SSD comparado ao write-through.

Answer 3

Seu armazenamento em cache de arquivos provavelmente está ajustado incorretamente para sua carga de trabalho. Infelizmente, o kernel do Linux é estúpido o suficiente para não lidar com isso automaticamente e os padrões são muito ruins se você tiver muita memória RAM e dispositivos de bloqueio suficientemente lentos. Consulte o link para obter detalhes.

Sugiro tentar modificar /etc/sysctl.conf

vm.dirty_background_ratio = 3
vm.dirty_ratio = 6

para reduzir drasticamente a pressão da RAM causada pelo cache de gravação para permitir que o kernel manipule melhor outras tarefas. Isso trará melhor latência para menor taxa de transferência.

Outra possibilidade é aumentar o cache, mas se o seu processo constantemente escrever novos dados o tempo todo, você atingirá uma latência muito ruim se o cache ficar cheio. Se você quiser experimentar, você pode fazer algo como

vm.dirty_background_ratio = 5
vm.dirty_ratio = 80

Observe que *_ratio configurações se referem à porcentagem de RAM disponível. Se você quiser um melhor controle, use as configurações de *_bytes . Eu pessoalmente uso a seguinte configuração para minha estação de trabalho:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000

Isso limita o cache de gravação em segundo plano a 50 MB e força a gravação em sincronia se 200 MB estiverem no cache.