Olá pessoal, hoje eu instalei o Xubuntu 18.04.04 e ao copiar arquivos em quantidades tipo 30, 50, 100 GB o sistema fica com alguns travamentos pensei que fosse o thunar então instalei o pcmanfm mas continuou tenho 8GB de memória, core i5-4300 2.6Ghz, HD 1TB, acontece com vocês também? Meu HD não apresenta falhas no gsmartcontrol e nem tenho problemas durante a utilização só quando faço cópias.
Esse é um problema recorrente em algumas configurações de hardware, não conheço nenhuma solução.
Nas máquinas que eu tenho aqui, não acontece, mas vários amigos tem esse problema.
1 curtida
Primeiro, tente com rsync, ferramentas de terminal tem muitos anos nas costas e costumam ser muito mais estáveis. Se isso não resolver, pode ser que o seu scheduler, seja o problema, verifique se seu scheduler é to tipo blk-mq, por exemplo BFQ é um scheduler do tipo blk-mq. Você pode ver o scheduler do dispositivo sda por exemplo com o seguinte comando:
cat /sys/block/sda/queue/scheduler
Resumindo, esse tipo de scheduler por ser multi-queue é mais eficiente quando ha muito IO ocorrendo, se o que você usa é do tipo antigo, muito provavelmente este é o problema.
1 curtida
Saída: [mq-deadline] none
Isso é uma constante que tenho passado em distribuições linux… Geralmente causada pelo cache de arquivos ser muito grande e interferir com a memória total.
Verifique se é mesmo essa condição desabilitando o swap e tentando a cópia.
sudo swappoff
Se não deu essa travada então precisa ajustar os valores que o sistema usa para o cache de arquivos. Primeiro remonte o swap
sudo mount -a
Daí vá ajustando os valores percentuais que podem ser utilizados para cache “limpo” e “sujo”. Comece sabendo quais são os valores atuais do seu computador:
cat /proc/sys/vm/dirty_background_ratio
cat /proc/sys/vm/dirty_ratio
Diminua pela metade esses valores:
sysctl vm.dirty_ratio=X
sysctl vm.dirty_background_ratio=Y
Teste novamente a copia dos arquivos. Se continuar travando, diminua de novo até o problema ser sanado. Aqui valores de 10 e 5 funcionaram bem (tenho 16G de ram).
Uma vez que ajustou os valores de forma que seu sistema funcione redondo, faça essas alterações definitivas editando o arquivo /etc/sysctl.conf incluindo ou editando as linhas:
sudo nano /etc/sysctl.conf
vm.dirty_background_ratio = XX
vm.dirty_ratio = YY
Explicação: O cache de memória “suja” ou “dirty” em inglês é o cache de bytes que ainda precisam ser escritos no disco. Quando o sistema de arquivos não é montado com a opção de cópia sincronizada “sync” o kernel faz de conta que gravou no disco, mas só colocou na memória como cache sujo. Como o arquivo é grande, não cabem todas as alterações na RAM e ele fica com uma batata quente na mão: O kernel entope a memória de cache sujo que precisa ser escrito no disco (o disco está a todo vapor) e algum programa pede um pouco mais memória, ele não tem memória livre e resolve usar o swap (só que o swap não funciona pq existe uma fila de operações pendente para gravar no disco). Os valores ajustados vão limitar essa quantidade de cache sujo num valor pequeno o suficiente para que essa manobra não interfira com a utilização do computador (o valor que foi ajustado representa o percentual de memória total a ser usado). Outra opção seria montar o sistema de arquivos com a opção de escrita sincronizada, pois nesse caso não será utilizado cache sujo (ou cópia assíncrona).
6 curtidas
Fiz o processo abaixo para disco rotativo os travamentos diminuíram porém o mode de trabalho do HD mudou, a rotação ficou mais expressiva não sei qual o impacto fiz por conta e risco.
O processo para mudar o escalonador de E/S, dependendo se o disco é rotativo ou não, pode ser automatizado e persistir entre reinicializações. Por exemplo a regra do udev abaixo define o escalonador como none para NVMe, mq-deadline para SSD/eMMC, e bfq para unidades de armazenamento rotativas:
/etc/udev/rules.d/60-ioschedulers.rules
Define o escalonador para NVMe
ACTION==“add|change”, KERNEL==“nvme[0-9]", ATTR{queue/scheduler}=“none”
Define o escalonador para SSD e eMMC
ACTION==“add|change”, KERNEL=="sd[a-z]|mmcblk[0-9]”, ATTR{queue/rotational}==“0”, ATTR{queue/scheduler}=“mq-deadline”
Define o escalonador para discos rotativos
ACTION==“add|change”, KERNEL==“sd[a-z]”, ATTR{queue/rotational}==“1”, ATTR{queue/scheduler}=“bfq”
Referência: https://wiki.archlinux.org/index.php/Improving_performance_(Português)
Aumento na velocidade de rotação vai aumentar o ruido e o consumo de energia, para dispositivos rotativos a informação mais relevante em termos de operação, para a vida útil, é a quantidade de partidas, por isso eu aconselho para quem quer fazer seus HDDs durarem mais, desligar o modo de economia de energia e também evitar ficar plugando e desplugando HDDs externos e desligando e ligando máquina com frequência maior que 2 vezes ao dia.
Enfim, se possível poste o resultado do cat para ambos os dispositivos envolvidos na transferência para sabermos se realmente seu scheduler mudo, pela última postagem parece que o módulo do scheduler BFQ não está ativado no seu sistema. Embora deadline-mq seja melhor que qualquer scheduler single-queued (é um scheduler blk-mq).
E esqueça essa distinção, o ArchWiki é uma ótima base de dados mas neste ponto eles estão errados, o próprio desenvolvedor do BFQ mostra que o scheduler é bom para SSDs e NVMes:
BFQ objetiva melhorar a responsividade de sistemas interativos durante atividades IO pesadas, eu apenas não o aconselharia se você você literalmente não estivesse tendo estes engasgos já que ele pode reduzir o throughput um pouco.
A dica do colega @Deleterium também é muito boa, eu aconselharia também testes com dirty_ratio mais altos e dirty_backgroud_ratio baixos, por exemplo 55 e 5, caso baixar ambos não tenha efeito, este benchmark demonstra diminuição na latência do sistema com dirty_ratio acima de 55%, mas é bom ter prudência, eu acredite que se trate de uma amostra onde escrita randômica é a atividade dominante e não transferências de grandes quantias de dados contínuos. Outra observação importante é que o dirty_ratio elevado resultou em mais picos, que podem levar a stuttering.
Outra consideração que você deve ter é quanto a natureza do que está transferindo para melhor entendermos as possíveis causas. É um grande arquivo zip/tar/etc ou são milhares de arquivos, com muitos arquivos pequenos? Você tem o mesmo problema transferindo arquivos inteiriços grandes ou uma porção de arquivos pequenos desse tamanho?
2 curtidas
Também tenho esse problema e creio que isso seja a causa de muitos problemas de performance no meu notebook. Mas para ser claro, o “travamento” que dá no meu sistema é que este quase congela quando um grande volume de dados é transferido, mas ao final da transferência tudo fica OK.
Acho que é porque é HDD, acredito que se fosse SSD eu não teria esse problema. Pretendo comprar um SDD o quanto antes.
O seu caso muito provavelmente vai se resolver com a dica do @Deleterium, parece o tipico caso de cache cheio onde o Kernel chega no limite do dirty ratio, obriga writeback síncrono congelando as aplicações em user space e forçando o sistema de arquivos a “manobrar” o cache com o swap para respeitar a ordem de escrita, provocando longas pausas em vez de stutters.
Nos SSDs mais novos (tlc ou qlc) também dá essa travada quando passa de 20 GB aqui. No SSD antigão que tenho (mlc) copia perfeito até o HD encher.
A questão com esses SSD mais novos é que eles tem um cache interno bastante rápido (geralmente em torno de 20GB) que é usado quando gravando dados nele, mas a memória padrão é a lenta para gravação. Fica praticamente igual um HDD quando a gravação supera todos esses limites (RAM + Cache do SSD). Aí também pode acontecer o stutering no SSD (possivelmente também nos NVME com flash TLC e QLC). Pro usuário comum dificilmente vai bater essa marca, mas pra quem usa edição de vídeo é um freio forte.
Tem um vídeo mostrando esse momento (no windows). Vale a pena ver o vídeo inteiro tmb, mas vou linkar só a parte do compartativo de gravação em disco.
1 curtida
Não sabia dessa “trapacinha” das empresas! 
Um último “bastião” pode ser usar o rsync com ionice para reduzir a demanda da transferência, espero que tenha conseguido aplicar as dicas e resolver o problema, esses congelamentos não deveriam ocorrer, já faz mais de 2 anos que não tenho problemas de stturrer ou congelamento com IO no Linux, seja nas máquinas com SSD ou HDD onde trabalho. Qualquer duvida chama.
Pois é, galera compra memoria flash de cartão de memória classe 10 e achando que tá no computador da NASA! É claro que pras necessidades do usuário comum está todo mundo feliz: eles anunciam aquela velocidade máxima do cache mas escondem a velocidade real e o usuário feliz não copia mais de 20G de dados de uma vez e não reclama do ssd lento.
Olha que o teste é com marca TOP, essas marcas de segunda linha para usuário doméstico devem ter menos cache ainda. Agora quem quer performance séria precisa ir pra linha industrial e o preço quintuplica!
Pra evitar isso em copias gigantescas que eu não necessito de velocidade extrema causando travamentos, tapei o sol com a peneira com o scp, que pode copiar arquivos localmente e possui controle da velocidade de cópia. Aqui no SSD podrex funcionou bem com esse comando:
scp -l 400000 arquivo_origem arquivo_destino (ele vai limitar em 400000 kbps, que divididos por 8 é 50000 kB/s, que divididos por 1000 são 50 MB/s)
Pois é eu não fazia ideia, sempre usei a linha PRO de SSDs e NVMes da Samsung ou os Optane da Intel e nunca tive esse problema, Por sorte nunca precisei de um SSD de 1TB.
Quanto ao scp eu só não recomendo por não permitir compressão nem checksum da transferência (principalmente este ponto, tornando a transferência “garantida” contra corrupção), transferência diferencial via delta mode que reduzem muito a transferência em diversos casos, etc.
A grande maioria das pessoas que eu vi com esse problema, usavam SSDs desse tipo.
Eu tenho um SSD e tenho o mesmo problema e acredito que não seja por conta das configs do meu notebook também.
i5 3337u 2.70 GHz
8GB RAM
240GB SSD
Com essas configs se eu tiver passando algum arquivo pro HD da umas travadas bem grande tem vez que chega a congela a tela. (O ssd é novo, não tem nem 4 meses que comprei e já fiz os testes nele e aparentemente está tudo ok com ele)
1 curtida