Desempenho lento ao copiar arquivos de e para dispositivos USB

Quando copio arquivos de e para dispositivos USB (câmera, HDD, cartão de memória), meu sistema fica muito lento. Por exemplo, se eu quiser fechar uma janela, movo o mouse, mas leva cerca de 2 segundos ou mais antes do cursor do mouse se mover. Quando finalmente coloco o cursor sobre o x e clico, nada acontece por mais de 10 segundos. Eu tentei isso com todos os efeitos da área de trabalho desativados, mas o problema persiste.

Software: Linux Mint 9 KDE Hardware:

• Placa-mãe Asus SLI
• GPU NVidia 6600
• 2 GB de RAM
• Swap de 2 GB
• AMD Athlox X2 @ 3800+

Para mim, esse hardware não deve ter problemas ao executar este software e não ocorre até eu copiar arquivos usando USB. Onde devo começar a procurar descobrir isso? Estou pensando que o driver gráfico pode fazer parte do problema, mas não tenho certeza.

Parece haver um problema com páginas enormes no gerenciamento de memória do Linux . Isso raramente ocorre, mas parece que você o observou.

Causa

Esta é minha conta grosseiramente simplificada do que, de acordo com o artigo, acontece.

Se azarado, um processo fica parado no momento em que emite um acesso à memória. Isso ocorre porque, quando grandes páginas transparentes são ativadas, um acesso à memória pode acionar a compactação síncrona (desfragmentação da memória principal) síncrona, o que significa que o acesso à memória não termina antes da compactação. Isso por si só não é uma coisa ruim. Porém, se a gravação (de, por exemplo, dados armazenados em buffer para USB) ocorrer ao mesmo tempo, é provável que a compactação, por sua vez, pare, aguardando a conclusão da gravação.

Portanto, qualquer processo pode acabar esperando que um dispositivo lento termine de gravar dados em buffer.

Cura

Atualizar a memória principal, como o OP, pode ajudar a atrasar o problema. Mas para aqueles que não consideram essa opção, existem duas soluções óbvias. Ambos envolvem recompilar o kernel:

• desativando o recurso transparente de páginas enormes
• aplicando o adesivo de Mel, conforme mencionado no artigo

Isso soa semelhante à minha pergunta aqui (onde uma resposta me indicou essa pergunta):

/programming/10105203/how-can-i-limit-the-cache-used-by-copying-so-there-is-still-memory-available-for

Mas a teoria é completamente diferente e a solução que usei não tem relação com a sua, mas funciona perfeitamente.

Eu estava usando o rsync, então tudo que eu precisava fazer era usar a opção --drop-cache. (o que torna a cópia um pouco mais lenta como efeito colateral)

O único truque que achei realmente funciona: o Gnome, os arquivos de cópia do nautilus para USB param a 100% ou perto

Se você quiser experimentar alguns truques para usuários avançados, poderá reduzir o tamanho do buffer usado pelo Linux configurando / proc / sys / vm / dirty_bytes para algo como 15728640 (15 MB). Isso significa que o aplicativo não pode ter mais de 15 MB à frente de seu progresso real.

Um efeito colateral é que seu computador pode ter uma taxa de transferência de gravação de dados mais baixa com essa configuração, mas, no geral, acho útil ver que um programa está em execução por um longo tempo enquanto grava muitos dados versus a confusão de ter um O programa parece ter sido concluído com o seu trabalho, mas o sistema está muito atrasado, pois o kernel faz o trabalho real. A configuração de dirty_bytes com um valor razoavelmente pequeno também pode ajudar a impedir que o sistema deixe de responder quando você está com pouca memória livre e executa um programa que repentinamente grava muitos dados.

Mas não o ajuste muito pequeno! Uso 15MB como uma estimativa aproximada de que o kernel pode liberar o buffer para um disco rígido normal em 1/4 de segundo ou menos. Isso evita que meu sistema fique "atrasado".