Ir ao conteúdo
Entre para seguir isso  

Como configurar SSDs no Linux para maior desempenho

       
 10.716 Visualizações    Tutoriais  
 18 comentários

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.

Como configurar SSDs no Linux para maior desempenho
Gabriel Torres Editor executivo do Clube do Hardware

Quando instalamos SSDs no Windows, o sistema operacional automaticamente ativa o comando TRIM (para evitar degradação desnecessária do SSD) e faz outros ajustes necessários para aumento de desempenho e vida útil. No Linux, porém, isso não é feito: são necessárias configurações adicionais.

Dois ajustes são necessários. Primeiro, edite /etc/fstab e localize a linha que monta o SSD. Será uma linha como:

UUID=9728b046-96eb-4c6f-ae60-31805ad8e320 /               ext4    errors=remount-ro 0       1

Nela, adicione noatime,nodiratime,discard ao lado de errors=remount-ro, ficando algo como:

UUID=9728b046-96eb-4c6f-ae60-31805ad8e320 /               ext4 noatime,nodiratime,discard,errors=remount-ro 0       1

O segundo ajuste que deve ser feito é adicionar a seguinte linha ao arquivo /etc/rc.local:

echo deadline > /sys/block/sda/queue/scheduler

Onde você deve substituir “sda” pela unidade que representa o SSD em sua máquina.

Reinicie a máquina.

Se você tiver um servidor MySQL na máquina, você pode configurar o MySQL a usar blocos de dados de 4 kiB para “casar” com o tamanho do bloco de dados usados no SSD e aumentar o desempenho. Para isso, você terá de obrigatoriamente usar o motor InnoDB em suas tabelas. O parâmetro que deve ser adicionado ao arquivo my.cnf é o seguinte:

innodb_page_size=4k

Se as tabelas dos bancos de dados já forem InnoDB, você terá de fazer um “dump” dos bancos de dados, apagar todos os bancos de dados, reconfigurar o MySQL com o parâmetro acima, recriar os bancos de dados e restaurar o “dump”. Isso ocorre porque os arquivos contendo os dados gerados com um determinado tamanho de bloco são incompatíveis com arquivos gerados com outro tamanho de bloco configurado.

Se as tabelas dos bancos de dados forem MyISAM, você deverá configurar o parâmetro acima e converter suas tabelas para InnoDB, lembrando que tabelas InnoDB consomem mais memória (RAM) e você possivelmente precisará fazer ajustes finos específicos ao InnoDB. Esses assuntos fogem ao escopo do presente tutorial.

Compartilhar



  Denunciar Artigo
Entre para seguir isso  

Comentários de usuários


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.

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

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?

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

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.

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

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!

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

@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

Editado por ilkyest

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

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.

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

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.....

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

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
 

Editado por NGC2071

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

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.

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

 

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

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites

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!

Compartilhar este comentário


Link para o comentário
Compartilhar em outros sites


Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário






Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas publicações sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×