Esclarecimento por favor no truque de disco lento

Question

Estou tendo problemas onde meus vários discos diminuem as taxas de transferência de cerca de 25 MB / s para cerca de 0,3 MB / s. Às vezes, uma reinicialização ajuda, mas não necessariamente por muito tempo. Eu tive isso com o Ubuntu Mate, substituí-lo pelo Xubuntu, mas sem sorte.

Então, pesquisando, mais uma vez, aleatoriamente, encontrei o tópico Queda de performance de E / S imprevisível e massiva no Linux

O autor disse que

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

trabalhou para ele. Sendo muito desesperado, eu tentei e funcionou . O disco USB parou de produzir ruídos quase imediatamente e retornou à velocidade normal.

Mas, francamente, eu não tenho absolutamente nenhuma idéia do que estou fazendo aqui. O que é /proc/sys/vm/drop_caches ? Este arquivo ainda está vazio após o eco? Por que isso funciona e há algum problema em fazer isso? Isso indica um problema de hardware?

Adendo 1: Implementei isso chamando um script executando sync e o echo no crontab raiz que executa as tarefas de backup. O principal trabalho de backup começa às 3:30 da manhã e eu chamo o script logo antes dele e também às 4 da manhã e às 5 da manhã. O backup só pareceu ter aumentado a velocidade após o script às 4 da manhã, portanto, não é muito simples implementá-lo. Mas eu posso agora razoavelmente executar backups do sistema durante a noite novamente.

Adendo 2: Talvez eu também deva salientar que em um ponto eu vi as taxas de transferência de 0,3 MB / s enquanto o IIRC copiava uma estrutura de 30 GB ou mais da Internet para o disco rígido interno do sistema. Portanto, não é óbvio para mim que o problema são os discos rígidos USB mais lentos (que não são particularmente lentos, na minha opinião, a 30 Mb / s ou mais quando o sistema está funcionando corretamente, como depois de escrever para / proc / sys / vm / dropped_caches.)

Adendo 3: alterar vm.dirty_background_ratio, vm.dirty_ratio, vm.dirty_expire_centisecs e vm.dirty_writeback_centisecs para o que eles estão no meu OK Laptop não fez diferença.

Adendo 4: Aparentemente este é um bug conhecido, link Um link útil de lá é link . Configurar GRUB_CMDLINE_LINUX="mem = 8192M" em / etc / default / grub, executar update-grub e reinicializar parece ter retornado a gravação em disco a uma velocidade razoável sem o uso de drop_caches. (Com a perda de 8GB de memória.)

    

Answer 1

Parece que você está experimentando o que está descrito aqui :

There is also the chance that a lot of I/O will overwhelm the cache, too. Ever written a lot of data to disk all at once, and seen large pauses on the system while it tries to deal with all that data? Those pauses are a result of the cache deciding that there’s too much data to be written asynchronously (as a non-blocking background operation, letting the application process continue), and switches to writing synchronously (blocking and making the process wait until the I/O is committed to disk)

Isso também é discutido neste artigo do LWN . Basicamente, sua unidade USB lenta pode manipular pequenas gravações constantes, mas quando sua tarefa de backup é executada, ela preenche o cache da VM e agora você obtém gravações síncronas lentas por algum tempo. "echo 3 > / proc / sys / vm / drop_caches" remove objetos limpos desses caches, permitindo que a E / S faça uso do cache, aumentando assim o desempenho.

Como sugerido nos links, experimente alterar os valores de "vm.dirty_ *". Por exemplo, vm.dirty_background_ratio e vm.dirty_ratio.

    

Answer 2

link

Writing to this will cause the kernel to drop clean caches, as well as reclaimable slab objects like dentries and inodes. Once dropped, their memory becomes free.

To free slab objects and pagecache: echo 3 > /proc/sys/vm/drop_caches

"cache limpo" é o cache que é o mesmo que o do disco, então você pode simplesmente soltá-lo e relê-lo do disco mais tarde.

Cache de páginas é o cache de páginas de memória lidas do disco: link

Slab é uma parte contígua da memória: link

    

Answer 3

Ter melhorias na E / S depois de informar ao kernel Linux para liberar / liberar memória alocada para caches é provavelmente um indicador de que você está tentando usar mais memória RAM do que aquela que você tem disponível.

Na falta de RAM física, o (s) sistema (s) recorrem à paginação, portanto, a degradação nas operações de E / S.

Eu investigaria se:

• a configuração do sistema pode ser otimizada;
• ou se você precisar de mais RAM física.

Veja Definindo / proc / sys / vm / drop_caches para limpar o cache para ver uma explicação mais detalhada do que você pode fazer sobre a queda de caches.