A desaceleração provavelmente está acontecendo por causa do iowait. O comando ionice deve permitir que você continue trabalhando:
ionice -c3 command
Eu comecei a desarquivar um arquivo RAR com vários gigabytes. O computador está indo muito devagar, está quase congelado. Às vezes eu posso mover o mouse um pouco, mas é isso. O processo de desarquivamento parece ter parado, então agora tudo o que posso fazer é reiniciar o sistema. Eu não acho que posso desarquivar este arquivo no Linux.
Eu nunca tive esse problema no Windows. Como isso pode ser corrigido?
A desaceleração provavelmente está acontecendo por causa do iowait. O comando ionice deve permitir que você continue trabalhando:
ionice -c3 command
Tente executar o comando com uma prioridade mais baixa usando o utilitário bom . A compactação de arquivos grandes pode ser exigente na CPU, por isso, normalmente, é uma das ferramentas usadas para medir o desempenho em comparações e benchmarks de CPU.
exemplo:
$ nice -15 ./myprogram
O número que você especifica é um ajuste do nível legal padrão. -20 sendo a prioridade mais alta e 19 sendo a mais baixa. Números negativos são reservados para o usuário root.
Eu também tive esse mesmo fenômeno, mas acho que encontrei a resposta. Eu costumava usar unrar em 1 disco, lendo e escrevendo. Como isso é muito, todos os outros processos não têm tempo para trabalhar no disco. Agora deixo unrar colocar os itens descompactados em outro disco, não em outra partição, nenhum outro disco físico. Tem várias vantagens:
É uma solução simples, mas funciona.
Eu encontrei a solução. Eu tenho uma máquina virtual do Windows já instalada no Linux. Eu compartilhei a pasta onde o arquivo está com a máquina virtual. Então, dentro do Windows, eu desarquivei o arquivo usando o 7-zip e tudo correu bem. Demorou muito tempo, mas não vi nenhuma diferença notável no desempenho do sistema. 7-zip não está disponível para Linux. O Windows ainda pode ser útil às vezes!
O desarquivamento de um arquivo grande não deve ser um problema, você está apenas vendo sintomas de outra coisa.
A sua partição Linux está próxima de sua capacidade? Como 95% completo ou mais? Se for esse o caso, muitos sistemas de arquivos (incluindo ext3, ext4 e reiserfs) ficarão muito mais lentos.
A velocidade de E / S do disco está OK no Linux? Os programas começarão em um tempo razoável, navegar pelos diretórios com um gerenciador de arquivos parecerá lento ou agitado? Você já tentou algum programa de benchmarking, como bonnie ++ ou ionice ?
O unarchiver aloca toda a memória disponível? Veja top ao tentar desarquivar esse pacote.
Às vezes, o agendador de E / S de disco cfq padrão pode levar a problemas estranhos durante as rajadas de atividade de disco de longa duração. Você pode tentar agendadores deadline ou antecipatórios . Por exemplo, deadline tende a ser muito bom com as cargas de trabalho do banco de dados, portanto, também pode funcionar nesse caso.
echo deadline >/sys/block/sda/queue/scheduler
ou
echo anticipatory >/sys/block/sda/queue/scheduler
Substitua sda pelo nome do seu disco rígido.
Isso será uma mudança temporária e, normalmente, eu não recomendaria alterar o cfq no uso da área de trabalho, mas se você está tendo outros problemas de I / O do que essa coisa de desarquivamento, pode valer a pena tentar. A menos que tudo isso seja apenas porque o unrar comeu toda a RAM ...: -)
Eu tive um problema semelhante com um grande arquivo .zip (1,4 Gb) que contém quase 200.000 arquivos pequenos. Meu Ubuntu 13.10 64 bit teria levado mais de 10 horas. Não congela, o sistema realmente não desacelera, é apenas que a descompressão é incrivelmente lenta.
Eu tentei a solução de máquina virtual mencionada acima, com o Virtualbox e o W7 64. Aqui vem a surpresa:
1) em primeiro lugar, compartilhei a pasta para a máquina virtual e tentei descompactá-la lá, no mesmo local (um virtual F: unit no W7) com 7-zip. Sem sorte, a mesma velocidade de baixa qualidade que levaria uma eternidade. O 7-zip relatou uma saída inicial de 200 Kb / s, mas continuou desacelerando até que eu parasse (menos de 100 kb / se um ETA de 7 horas, mas provavelmente teria desacelerado mais e demorado mais).
2) depois mudei o arquivo .zip para dentro da "unidade de disco rígido" da máquina virtual (o que a vm acredita ser um HDD). O arquivo não estava em uma pasta compartilhada com o Ubuntu . Surpresa, surpresa, funciona muito bem, com cerca de 2000 Kb / s de saída, então levou menos de 15 minutos.
3) anecdotally, um sistema Windows 7 de 32 bits (não uma máquina virtual) com exatamente o mesmo hardware levou cerca de uma hora, com uma saída estável em torno de 500 kb / s, de acordo com 7-zip. Não tenho ideia de como a alteração de 32 a 64 bits afeta a descompactação de arquivos, apenas achei que seria bom mencionar para comparar.
Ubuntu 13.10 64 bits com ext4, W7 com NTFS tanto o sistema vm 64 bits quanto o sistema normal de 32 bits. O que realmente me deixa perplexo é o fato de que o W7 vm está realmente usando o sistema de arquivos ext4 subjacente, porque ele é um vm e ainda alcança essas velocidades.
Espero que alguns gurus leiam isso e descubram isso, isso é extremamente irritante e intrigante.
É provavelmente porque você está sem RAM. Você pode reparticionar seu disco rígido para incluir uma grande partição de troca, mas só isso, AFAIK.
Tags rar linux ubuntu ubuntu-10.04 archiving