Como configurar SSDs no Linux para maior desempenho

[Gabriel Torres]

Tópico para a discussão do seguinte conteúdo publicado no Clube do Hardware:

Como configurar SSDs no Linux para maior desempenho

"No Linux, você precisa efetuar configurações adicionais para obter o máximo de desempenho que SSDs são capazes de oferecer, bem como aumentar a vida útil do componente. Veja como."

Comentários são bem-vindos.

Atenciosamente,
Equipe Clube do Hardware
https://www.clubedohardware.com.br

[Jeremias Alves Queiroz]

Excelente tutorial, espero ver mais coisa bacana de Linux por aqui.

[Padre Vuador]

Excelente tutorial, espero ver mais coisa bacana de Linux por aqui.

 

Era exatamente isso que eu iria dizer. Se eu num fosse fanatico em games eu tinha instalado aqui o Ubuntu.

[Eruru]

No comando do artigo as vezes a distância entre uma palavra e outra é de vários espaços. Como fazer igual sem ctrl+c ctrl+v?

[Gabriel Torres]

Clica com o botão direito e visualize o código fonte da página... Infelizmente por causa do altíssimo índice de plágio do nosso site não temos como liberar o control C + control V.

[Daniel De Martins Scherer]

Excelente tutorial, simples e direto, muito bom pra quem não tem conhecimento técnico e utiliza o sistema pelas inúmeras vantagens em relação ao Windows. Também gostaria de ver mais conteúdo sobre Linux e Software Livre no site!

[Gabriel Torres]

@Jeremias Alves Queiroz

@Daniel De Martins Scherer

 

Obrigado pela força, vou tentar então postar mais dicas sobre o Linux. Abraços!

[ilkyest]

@Gabriel Torres usando o bfq, para kerneis preparados, também seria bastante interessante. O deadline larga tudo em últimos... já o bfq usa "a tecnologia" do linux de avaliar o que é melhor.

 

Outra coisa que dou a dica

 

Existe um workaround, principalmente em algumas unidades específicas. Não notei no linux, no caso, em SSD, porque "non tengo plata ainda" para montar um sistema baseado no que eu quero/preciso. Mas, eu vi alguns comentando, principalmente em ambientes ligados ao KDE

 

o comando

echo madvise > /sys/kernel/mm/transparent_hugepage/defrag

 

Eu uso o arch linux, apenas... e tive um contratempo com perda de resposta em USB no KDE.

 

Seria interessante, talvez, analisar isso.

 

O SSD é muito rápido. Eu não entendo porque esse problema afeta o KDE em específico, até sugeriria ao pessoal fazer o teste em SSD e ver se dá diferença, principalmente, com arquivos grandes, um zip por exemplo com mais de 10Gb.

 

E outra dica. Algumas distros não usam o UUID. então seria interessante um 

 

lsblk

 

Para ver o leiaute do formato de arquivo/unidades antes de gerar os comandos

[Gabriel Torres]

@ilkyest obrigado pelas dicas. Eu uso o Debian, e usei o deadline pois é o que é recomendado na documentação oficial. Abraços!

[Internet]

Artigo interessante, cabe algumas observações:

 

1. Não vejo tanta necessidade assim em alterar os parâmetros padrão sobre a questão do acesso, adicionando noatime e o no diartime. Eu acho que o parâmetro padrão do kernel (que é o relatime) é uma opção mais segura, evitando problemas com alguns programas, principalmente com indexadores.

http://lwn.net/Articles/244829/

 

2. Sobre o deadline, é mais elegante colocá-lo nas opções do gerenciador de boot, colocando elevator=deadline na linha de opções do kernel, ao invés de usar o rc.local para esse fim.

 

3. O uso do parâmetro discard (ou seja, TRIM em tempo real) nem sempre tem funcionado muito bem no Linux, demonstrando casos aleatórios de comprometimento na performance, principalmente com SSDs de controlador SandForce. Uma alternativa para isso é usar o fstrim manualmente (fstrim -v ponto_de_montagem). Para facilitar a coisa, você pode colocar o fstrim para ser executado via cron.

[ilkyest]

eu sou resiliente em usar o trim e o deadline com algumas distros como o ubuntu, que não me pareceu "tão resolvido" quanto ao problema dos hds de notebook... eu vi relatos de alguns colegas que tiveram o mesmo problema com SSDs.

 

eu usaria o deadline, mas sem o trim.....

[Gabriel Torres]

@ignacho excelentes dicas, bem didática a sua explicação, obrigado pela colaboração.

[NGC2071]

Eu fiz algumas coisas a mais, não sei se realmente produzem diferença no desempenho. Mas pela dor de cabeça que me deu, acho que vale a pena compartilhar, para que outros não percam tempo à toa.

Uso o Fedora 20 e mais ou menos o passo a passo que fiz foi:

- Primeiro passo (antes de formatar a unidade), verificar se a opção AHCI do BIOS está habilitada [1]. É importante para que opção TRIM funcione.

- Segundo, sobre o journaling do Ext4 [2]. Você pode:

• Habilitar o modo writeback do journaling. Assim, o journaling pode ser gravado antes do dado real ser gravado (gravação fora de ordem). O problema da opção é que numa derrubada abrupta do sistema alguns arquivo podem aparecer com valores antigos [3].
  • tune2fs -o journal_data_writeback /dev/sda1
• Ou desabilitar completamente journaling.
  • tune2fs -O ^has_journal /dev/sda1
• Eu escolhi desabilitar o journaling. No fundo eu fiz os dois, mas foi mais por preguiça de estudo do que isso ser uma necessidade.

- Terceiro, fstab, além do que o Gabriel disse, você terá de adiconar mais algumas coisas (mais informações em [3]):

• discard,noatime,data=writeback,commit=60
• Eu li em algum lugar (sinto muito pela falta de referência, mas nada que uma googlada não ache) que nodiartime está contido na opção noatime, então se você opta por noatime, não precisa especificar nodiartime.
• A opção data=writeback só vai funcionar se você tiver a habilitado com o tune2fs, caso contrário o disco não vai montar. O commit é o tempo para sincronizar dados e metadados (isto é, deixar o journaling em dia) a cada X segundos. No caso acima é a cada X = 60 segundos.
• Novamente, eu digo que eu acredito que essas opções não fazem sentido se o journaling estiver desligado, mas isso carece de maior investigação. Eu acabei deixando assim.

-  Quarto, grub.

• Além da alteração que o ignacho disse, para modificar o io scheduler do linux [6], encontrei em vários tópicos dizendo que a adição de libata.force=noncq diminui a instabilidade do SSD [4].

- Quinto, swap.

• Convém deixar o swap em um disco que não seja o SSD caso você possa fazer isso (em caso de notebook é difícil).
• Adicionando no arquivo /etc/sysctl.conf a linha vm.swappiness=1, você faz com que o sistema operacional evite ao máximo usar o swap. Caso você tenha bastante memória pode até desabilitar vm.swappinees=0. [5]

- Sexto, /var/spool, /var/log, /tmp....

• O diretórios /tmp, /var/spool, /var/log, /var/tmp, recebem bastante escrita. Há duas opções, mountar esse diretório em partições separadas (eu particularmente, monto /tmp e /var inteiramente em partições separadas) ou montá-los na memória usando fstab, por exemplo, tmpfs /var/spool tmpfs defaults,noatime 0 0.
• O problema de montar os diretórios na memória é que você, por exemplo, ficará sem log.

- Sétimo, caching de browsers.

• Você pode remover o caching dos browsers ou montar os diretórios usados para o caching na memória, ou em outra partição. Depende da sua possibilidade. Como o meu /home é montada em um disco comum, eu não tive freezing com browsers.

Um adendo é se você estiver usando a útlima versão do kde (a minha atual é a 4.13.3). Acho que você vai ficar muito feliz se desabilitar o indexador dele: sudo balooctl stop && sudo balooctl disable. Eu reformatei todo o computador só por conta dele, para só então descobrir que era ele quem causava freezing no linux. O que me ajudou a descobrir isso foi o iotop.

Um último detalhe do Fedora 20. Um mv /var/log/journaling para /var/log/journaling.old, pode deixar sua inicialização bem mais rápido. Porém, já digo que não sei os efeitos práticos disso: vulgo, fiz e até agpra não deu problema.

Se alguém achar algumas opções muito radicais, a minha decisão particular foi maximar operações de leitura na unidade SSD e minimar escrita, tentando redirecioná-las ao máximo para discos comuns. Por dois motivos: escritas não são tão rápidas em SSDs, principalmente os mais baratinhos que gravam mais de um bit por célula/transistor. Além disso, a escrita desgasta a célula e, novamente, as unidades SSDs baratinhas que gravam mais de um bit por célula acabam se desgastando mais [7].

Enfim, com essas configurações eu tenho tido bons resultados, até agora bem satisfatórios.


[1] https://wiki.freeswitch.org/wiki/SSD_Tuning_for_Linux
[2] http://askubuntu.com/questions/76913/how-can-i-check-if-a-particular-partition-ext4-is-journaled
[3] http://linux.die.net/man/8/mount
[4] http://lukewickstead.wordpress.com/2013/02/10/ssd-instability-under-linux/
[5] http://en.wikipedia.org/wiki/Swappiness
[6] https://www.ibm.com/developerworks/community/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/ssd_no_desktop_linux_parte_2?lang=en
[7] http://www.eetimes.com/document.asp?doc_id=1279762
 

[freire_83]

Segue algumas dicas interessantes para linux (em inglês):

 

https://sites.google.com/site/easylinuxtipsproject/ssd

 

OBS.: com relação ao TRIM a versão mais recente do ubuntu já vem com ele ativado por padrão para SSD's da Intel e da Samsung.

[Gabriel Torres]

@NGC2071 e @freire_83 Obrigado por sua colaboração, com certeza vai ajudar outros usuários interessados no tema!

[Celio Alves]

O Deadline vem como padrão no Ubuntu.

 

Como uso HD (um Hitachi IDE de 2007) o mais interessante para mim é o CFQ, que em vez de dar prioridade a leitura ou escrita, tenta dar atenção as duas requisições ao mesmo tempo. É do tipo que mesmo que o HD esteja ocupado com várias tarefas, não te deixa na mão quando precisar iniciar mais uma nova. Quando faço uma nova instalação do Ubuntu (ou outra distribuição), é uma das primeiras coisas que faço é mudar para CFQ. E pelos testes que fiz aqui, o CFQ junto com o sistema de arquivos Btrfs funciona lindamente com os tradicionais HDs.

 

Há quem diga que os SSDs funcionam bem com o Noop, já que este funciona de uma maneira simples: dá prioridade para aquela operação que chegar primeiro (seja leitura ou escrita), enquanto a seguinte espera a sua vez na fila.

[ilkyest]

 

Há quem diga que os SSDs funcionam bem com o Noop, já que este funciona de uma maneira simples: dá prioridade para aquela operação que chegar primeiro (seja leitura ou escrita), enquanto a seguinte espera a sua vez na fila.

O BFQ em alguns ambientes de teste que fiz, no caso, processador AMD, rodando o folding at home, e ouvindo música da internet, por exemplo, revela-se muito tenebroso. Usar o CFQ com baixa latencia de kernel é judiaria... o ubuntu, se me lembro, traz um kernel frequency de 1khz, bom, bom mesmo....

 

o noop, na verdade, não é o melhor... o deadline usa "ao máximo" tudo... o noop deixa as coisas como estão, sem nenhum aprimoramento. O Cfq, por padrão em alguns kerneis, tem sido o melhor por enquanto

[André Ricardo_354524]

Bom que o Windows já faz tudo isso automaticamente.

[Pedro.comminato]

Bom que o Windows já faz tudo isso automaticamente.

Mas nem todos preferem Windows! EU, particularmente só uso por conta da compatibilidade com Games, rodo muitos jogos na máquia aqui em casa! 

Mas se a biblioteca de programas, games e aplicativos fossem iguais, eu iria sem duvida de Linux!