Otimizando o desempenho de SSDs

Veremos aqui algumas alterações que visam melhorar o desempenho em discos SSDs (Solid State Disks).

Nas imagens abaixo (da 1ª versão desta dica, de 19/04/2012) vemos rodando num NetBook Acer Aspire One o Lubuntu 11.10:

Este slideshow necessita de JavaScript.

As alterações envolvem a edição dos seguintes arquivos de configuração:

/etc/default/grub
/etc/fstab
/etc/rc.local

Sistema de Arquivos.

A ideia básica por trás dessas alterações visa reduzir o tempo de escrita|acessos a esses discos e com isso prolongar o tempo de vida dos mesmos.

Segundo o artigo no qual essa dica se baseia (tradução livre):

Por padrão, muitas distribuições, incluindo o Ubuntu usa a opção ‘relatime’ para atualizar metadados do arquivos quando os mesmos são acessados e que é improvável que nos preocupamos com os tempos dos últimos acessos.

continuando…

Além disso, o Linux suporta TRIM com Ext4. TRIM é importante para manter o desempenho de um SSD quando arquivos são adicionados, apagados e modificados e permite que o SSD saiba quais blocos podem ser seguramente apagados. Nenhuma distribuição atualmente habilita esta opção por padrão, mas isso é simples de fazer, basta adicioanr a opção ‘discard’ para quaisquer dos SSDs montados.

mãos à obra!

Pelo longo tempo deixado de lado até que não houve tantas atualizações em meu Debian Wheezy, apenas 200MB:

$ sudo apt-get update
$ sudo debdelta-upgrade
$ sudo apt-get dist-upgrade

Este slideshow necessita de JavaScript.

Feito isto comecei pela edição do arquivo /etc/fstab…

$ sudo nano /etc/fstab

Localize a(s) linha(s) referente(s) a(s) montagem(ns) de sua(s) partição(ões) ext4 e troque o que lá estiver (por exemplo):

/dev/sda1 / ext4 errors=remount-ro 0 1
/dev/sda2 /home ext4 defaults 0 2

por (exemplo das minhas partições / e /home):

UUID=270c9e13-62b4-44e4-b298-dc961ec40a35 / ext4 noatime,nodiratime,discard,errors=remount-ro 0 1
UUID=d8864a6d-093d-49789a692-58e0857ba777 /home ext4 noatime,nodiratime,discard,defaults 0 2

Lembrando que eu utilizo as UUIDs das partições para identificá-las.

Antes o esquema de montagem era este:

UUID=270c9e13-62b4-44e4-b298-dc961ec40a35 / ext4 errors=remount-ro 0 1
UUID=d8864a6d-093d-49789a692-58e0857ba777 /home ext4 defaults 0 2

Em tempo.

Existem duas formas para descobrirmos a UUID de um dispositivo, usando o comando blkid que no Debian e derivados está disponível no pacote util-linux.

$ sudo blkid

ou utilizando o comando ls:

$ ls -al /dev/disk/by-uuid/

O Agendador do kernel.

O agendador (scheduler) organiza a leitura|escrita na fila de I/O de forma a maximizar o desempenho. O agendador padrão no kernel do Linux é o CFQ (Completely Fair Queuing) que foi concebido para tratar das latências de rotação de unidades giratórias tendo os tradicionais HDs e seus pratos em mente, assim sendo, ele funciona bem para discos rígidos padrão, porém, não funciona tão bem quando se trata de SSDs.

Felizmente, o kernel vem com alguns outros agendadores…

Alterar o agendador é fácil, e ainda melhor… podemos fazê-lo tomando um dispositivo como base, digamos que existam numa mesma máquina discos SSDs e discos rígidos tradicionais? simples! usa-se deadline para os SSDs e cfq para os discos tradicionais.

Executando…

$ sudo nano /etc/rc.local

Adicione o modelo abaixo para cada dispositivo SSD existente no sistema, antes do campo exit 0:

echo deadline > /sys/block/sda/queue/scheduler
echo cfq > /sys/block/sdb/queue/scheduler ### este último apenas se possui um disco rígido!!!

* Lembre-se de inserir a identificação correta do dispositivo!!!

Caso existam apenas SSDs em seu sistema, defina uma política global de forma a aplicar as alterações a todos os dispositivos já a partir do boot do sistema, para esse caso acrescente a opção elevator=deadline ao final da linha GRUB_CMDLINE_LINUX_DEFAULT no arquivo /etc/default/grub:

$ sudo nano /etc/default/grub

Deixe a linha parecida com esta:

GRUB_CMDLINE_LINUX_DEFAULT="quiet elevator=deadline"

E em seguida, execute:

$ sudo update-grub

Em algumas distros onde o comando update-grub não existe, o comando a ser executado é o seguinte:

$ sudo grub-mkconfig -o /boot/grub/grub.cfg

Arquivo de troca Swap e partição de arquivos temporários.

Utilizar ou manter uma partição SWAP configurada só é interessante quando realmente a mesma é constantemente utilizada e ao longo dos anos utilizando Linux, foram poucas as vezes que vi essa utilização, seu uso ocorre com frequência em máquinas com pouca RAM ou naquelas que usam o benefício de hibernação (como no caso dos portáteis).

Em máquinas onde a quantidade de RAM é suficiente uma boa idéia é simplesmente adicionar uma opção ao arquivo /etc/rc.local de forma que a SWAP só seja utilizada quando toda a RAM do Sistema for utilizada, isso não é nada de novo, mas de fato vale a pena e é melhor que desativar a Swap, vamos lá!

$ sudo nano /etc/rc.local

Adicione a linha abaixo ao final do arquivo e antes da linha exit 0:

echo 0 > /proc/sys/vm/swappiness

E para concluir, ou seja, para reduzir ainda mais escritas desnecessárias no SSD, podemos optar por mover o diretório /tmp para uma ram disk utilizando o sistema de arquivos ‘tmpfs’ que é expandido e reduzido dinâmicamente quando necessário.

Tomando como exemplo as sugestões do artigo, acrescentei apenas as três linhas abaixo no meu arquivo /etc/fstab:

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0

Mas tive problemas com o SQUID e alterei um pouco , logo deixei meu /etc/fstab assim:

tmpfs /tmp tmpfs noexec,nosuid,nodev,noatime,mode=1777,size=512M 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0

* na 1ª linha 512M equivale à metade da RAM física.

Wheezy rodando sem o SQUID…

Ou seja, das sugestões originais tive problemas com duas das opções de montagens sugeridas, em ambas com o SQUID, se não usá-lo ao menos teste-as, as mesmas são as seguintes:

tmpfs /var/spool tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0

Nos diretórios /var/log e /var/spool estão localizados as pastas de cache (var/spool/squid) e de log (var/log/squid) que fazem parte das configurações padrão do Squid 2.7.STABLE9 do Debian.

* talvez modificando as permissões das pastas para 777 por exemplo, quem sabe não role!

Wheezy rodando com o SQUID…

Observação Importante!

Uma observação importante referente a essa última linha (/var/log…), pois utilizando-as poderão ocorrer perda de logs entre os boots do sistema, se você não se importa com isso: mande bala! do contrário: esqueça-a!

Em imagens, seguem os exemplos dos meus arquivos de configuração:

/etc/default/grub.

o arquivo /etc/default/grub…

/etc/rc.local.

O arquivo /etc/rc.local…

/etc/fstab.

O arquivo /etc/fstab…

Conclusão.

O arquivo original é mais abrangente que este, mas na máquina onde foram realizadas as alterações não existem discos rígidos tradicionais, tampouco outro SSD, a quantidade de RAM é suficiente para um Debian com OpenBox e também não tive quaisquer problemas com os navegadores (cache de arquivos) que justificassem extender a dica ainda mais.

Uma screenshot desde NoBo rodando o Debian Wheezy pode ser vista no link abaixo:

https://edpsblog.wordpress.com/2013/07/06/screenshot-wheezy-acer-aone/

Referência.

http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm