Como baixar, compilar e instalar fácil o glmark2 no Debian

O glmark2 é um aplicativo popular, de código aberto, usado para avaliar o desempenho da placa gráfica no sistema, com suporte a OpenGL 2.0 e OpenGLES 2.0.
A ferramenta está disponível para as plataformas GNU/Linux e Android.
Se você usa Ubuntu ou openSUSE, recomendo ler o post Guia para testar a performance do seu sistema com OpenGL, onde abordo a instalação do glmark2 nestas duas distros, a partir de seus repositórios específicos.
Naquele post, abordo também algumas dicas de uso do glmark2 —. Sugiro ler enquanto instala.
O glmark2 foi desenvolvido pela equipe da Linaro, com o objetivo de oferecer uma ferramenta de fácil uso para fazer benchmarking de unidades de processamento gráfico (GPUs) em hardware ARM, para sistemas embarcados.
Enquanto o aplicativo está disponível nos repositórios de outras distros, (Ubuntu, openSUSE etc), no Debian será necessário baixar e compilar o código fonte.
Se você é iniciante, no Linux, não se preocupe — por que é fácil.

Se você conhece os benefícios de baixar o código e compilá-lo no seu sistema e deseja usar este processo no Ubuntu, fique à vontade. Vai funcionar perfeitamente.

OpenGL oficial logo

Como preparar o ambiente para tratar o código

Para poder compilar código em seu sistema é necessário ter algumas ferramentas de desenvolvimento.
Neste caso, precisamos do git, do g++ e de algumas bibliotecas apropriadas.
Abra um terminal e instale-as:

sudo aptitude update
sudo aptitude install git g++ build-essential pkg-config

Com este comando, você estabelece um ambiente de desenvolvimento bem básico voltado para C++.
A seguir, instale as ferramentas de desenvolvimento X11 e OpenGL:

sudo aptitude install libx11-dev libgl1-mesa-dev

… e os headers de desenvolvimento para imagens JPEG e PNG:

sudo aptitude install libjpeg-dev libpng12-dev

Como baixar o código do glmark2

Agora já é possível receber o código e trabalhar em cima dele.
Para fazer o download, podemos usar o git ou ir até o site oficial do glmark2 e baixar o código.
Para baixar o código para dentro da minha pasta bin/ vou proceder da seguinte maneira:

cd ~/bin
git clone https://github.com/glmark2/glmark2.git
cd glmark2/

Como configurar, compilar e instalar

O glmark2 usa o sistema de desenvolvimento WAF, baseado no Python.
Este sistema requer uma instalação funcional Python 2.x.
A versão binária, disponível nos repositórios das outras distros, vem com suporte ao X11, Wayland e Mir.
A que nós vamos compilar, terá suporte apenas ao X11 e OpenGL:

./waf configure --with-flavors=x11-gl

Parte da graça de compilar um programa a partir do código fonte é poder retirar o que não é necessário, enxugar o código e ter um executável/binário mais rápido e eficiente.
As outras opções, caso queira acrescentar suporte a mais tecnologias, são as que seguem:

./waf configure --with-flavors=drm-gl,drm-glesv2,mir-gl,mir-glesv2,wayland-gl,wayland-glesv2,x11-gl,x11-glesv

Note que cada uma destas outras opções demanda um conjunto adicional de bibliotecas de suporte. Se você não as tiver, irá obter mensagens de erro ou avisos de que algo está faltando.
Quando terminar esta parte, construa o código e instale o binário:

./waf build -j 4
sudo ./waf install

Por fim, aplique o procedimento do stripping, que irá reduzir o tamanho final do binário e, portanto, torná-lo mais rápido.

sudo strip -s /usr/local/bin/glmark2

O processo está finalizado e você já pode rodar o glmark2 para verificar os resultados.

glmark2

Para concluir, você pode rodar o autoremove do aptitude e apagar o diretório com os fontes do glmark2 — mas, neste último caso, você terá que baixar tudo de novo, para fazer alguma alteração posterior no programa.

Referências

https://github.com/glmark2/glmark2.
http://fixmynix.com/how-to-install-glmark2-from-source-in-debian/.

Como testar o desempenho da placa gráfica no Linux usando o Unigine

O Unigine Heaven e o Unigine Valley são ferramentas de benchmarking proprietárias, de código fechado, desenvolvidas pela empresa russa Unigine.
A companhia focaliza o universo das soluções de alta performance, em 3D real-time.
Com a exibição de mundos 3D virtuais e gráficos impactantes a ferramenta é capaz de testar todo o potencial do seu hardware o que inclui o desempenho da sua GPU (placa gráfica).

Os softwares de benchmarking, alvos deste post, são multiplataforma e rodam no Linux, Windows e MacOS.

Unigine logo
A empresa desenvolve softwares para a AMD, NVIDIA, para a plataforma PLAYSTATION etc.
Neste texto, vou mostrar como baixar e rodar o programa de testes gráficos da empresa.
O download pode ser feito direto no site da empresa, aqui.
Outras opções de download, via torrent:

Os dois têm funcionamento semelhante (quase igual).
Saliento que o post é baseado em uma máquina rodando com uma placa gráfica Intel (integrada à placa mãe) comum, sob o OpenSUSE Leap 42.1.
unigine Heaven main screen
Há algumas opções a mais, presentes no Valley — mas ambos fazem uma análise profunda do desempenho gráfico do seu sistema.
Nenhum deles “deu pau” nas minhas máquinas de testes. Quando a exigência é muito grande para o seu hardware, o programa tende a finalizar a bateria e voltar para o menu inicial graciosamente.
Recomendo iniciar os testes com as opções mínimas ou Basic.
Observe, no canto superior esquerdo da tela, à medida em que o vídeo é exibido, a taxa de FPS.
Você pode ver mais informações no canto inferior direito da tela, se clicar no botão Benchmark, no canto superior esquerdo.

Como instalar o Unigine Benchmark tool

Feito o download, abra um terminal e vá até o diretório em que o pacote baixado se encontra. Trata-se de um pacote comprimido que se auto-extrai.
Para poder executá-los, é necessário dar-lhes permissões de execução:

chmod +x Unigine_Valley-1.0.run Unigine_Heaven-4.0.run

em seguida, execute os dois pacotes .run:

Unigine_Heaven-4.0.run; Unigine_Valley-1.0.run

Para executar o Heaven, dê o seguinte comando:

cd Unigine_Heaven-4.0/
./heaven

Para executar o Valley, dê o seguinte comando:

cd Unigine_Valley-1.0/
./valley

Conheça outras formas de testar suas placas gráficas no Linux.
Se quiser comentar sobre os resultados, logo abaixo, sinta-se à vontade.
unigine running benchmark tests

Guia prático para testar a performance do seu sistema com o OpenGL no Linux.

O OpenGL é um ambiente para desenvolvimento de aplicações móveis e interativas, com gráficos 2D e 3D.
Desde sua introdução, em 1992, o OpenGL se tornou a API mais difundida na indústria de softwares — o que possibilita a criação de milhares de aplicativos em uma grande variedade de plataformas.
OpenGL oficial logo
A escalabilidade da API do OpenGL permite que se rode aplicações em pequenos eletrodomésticos, aparelhos móveis, PCs/notebooks, workstations e supercomputadores.
Desenvolvedores podem trabalhar com e para qualquer plataforma, usando a API.
O OpenGL tem suporte para todos os UNIX, todas as versões do Windows (desde a 95), para o MacOS e, é claro, para o Linux.
A API pode ser chamada de praticamente todas as linguagens de programação importantes — Ada, C, C++, Fortran, Python, Perl, Java etc.
Neste artigo, vou mostrar como testar a performance do seu sistema Linux em relação ao OpenGL.
Para realizar os testes, usarei uma máquina com openSUSE Leap 42.1 e outra com Ubuntu 16.04 LTS.
Os aplicativos usados nos exemplos são universais e, caso sua distro GNU/Linux seja outra, não será difícil encontrá-los para baixar — se já não estiverem instalados.

A performance da sua placa gráfica no Linux

Apesar de ser famoso pela sua estabilidade e eficiência, como plataforma para realizar diversas tarefas, o Linux não é conhecido como plataforma excepcional para jogos — o que é uma injustiça.
Como consequência, não temos muitas ferramentas de benchmarking, de medição precisa da performance do hardware gráfico.
Ferramentas, estas, que poderiam nos ajudar a tirar conclusões mais sólidas e fazer comparações técnicas entre produtos e determinar exatamente o quão bem as coisas funcionam.
Enfim, todas as ferramentas de benchmarking disponíveis atualmente, para a plataforma Linux, rodam apenas sob a renderização da API do OpenGL.
Ainda que sua unidade de processamento gráfico (ou GPU) tenha compatibilidade com alguma versão do Direct3D… não será possível testá-las, neste quesito, usando Linux.
linux penguin

Use o GLX-Gears para experimentar o OpenGL no Linux

Este é um aplicativo popular e tradicional para testar o suporte ao OpenGL, no Linux (e em outros sistemas operacionais).
O glxgears faz parte do pacote de softwares ‘mesa-utils’.
No Ubuntu, você pode instalá-o com o apt (ou aptitude, no Debian):

sudo apt install mesa-utils

No openSUSE, use a ferramenta de gestão de pacotes, zypper para instalar o ‘mesa-demo-x’:

sudo zypper install mesa-demo-x

A partir daqui, já é possível usar as ferramentas glxinfo e glxgears.
Ao executar o comando glxgears, vai abrir uma janela, com uma renderização clássica do OpenGL, que mostra um conjunto de 3 rodas dentadas ou engrenagens.
Você pode verificar o frame rate ou FPS no terminal, em que você o executou, a cada 5 segundos.
glxgears
Trata-se de uma ferramenta bastante antiga.
O aplicativo glxgears é muito básico e testa apenas uma porção pequena das possibilidades que o OpenGL oferece hoje.
Quando foi concebido, era usado para determinar se o driver proprietário da placa de vídeo estava instalado e funcionando corretamente em comparação com a versão de código aberto ou open source. Você não perceberia a diferença nos dias de hoje, contudo.

Como testar o OpenGL com o glmark2

Você pode instalar o glmark2, no Ubuntu, com o apt:

sudo apt install glmark2

Para instalar no openSUSE, siga os passos:

sudo zypper addrepo http://download.opensuse.org/repositories/home:ykoba/openSUSE_Leap_42.1/home:ykoba.repo
sudo zypper refresh
sudo zypper install glmark2

Para instalar o glmark2 no Debian, siga estas instruções.
Novamente, o programa deve ser executado no terminal, onde você poderá observar os resultados dos diversos testes que ele irá realizar — que podem ser vistos em uma janela à parte, tal como no glxgears.

glmark2

O aplicativo renderiza diversos tipos de imagens e gráficos em 2D e 3D, na tela e mede o desempenho em FPS.
Finalmente, calcula a média dos resultados dos testes e dá uma pontuação para a sua GPU.
Esta pontuação pode ser usada como parâmetro comparativo entre diversas máquinas/placas gráficas.
Alguns parâmetros de uso interessantes do glmark2 podem ser os seguintes:
O exemplo, que segue, apenas valida os diversos tipos de testes em relação ao seu hardware de renderização gráfica.

glmark2 --validate

O exemplo, abaixo, roda o aplicativo em tela cheia — útil quando você só deseja saber o resultado final e não tem a intenção de acompanhar os testes uma a um.

glmark2 --fullscreen

O resultado do programa executado em uma janela vai ser diferente de quando for executado em tela cheia. Resoluções diferentes tem intensidade diferente de uso do hardware, como será possível observar nos próximos testes.
Você pode rodar benchmarks específicos, se quiser.
Para rodar apenas o pulsar, use o seguinte procedimento:

glmark2 --benchmark pulsar

O resultado se refere apenas ao módulo testado:

=======================================================
    glmark2 2014.03
=======================================================
    OpenGL Information
    GL_VENDOR:     Intel Open Source Technology Center
    GL_RENDERER:   Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 
    GL_VERSION:    3.0 Mesa 11.0.8
=======================================================
[pulsar] <default>: FPS: 1389 FrameTime: 0.720 ms
=======================================================
                                  glmark2 Score: 1389 
=======================================================

Você pode usar o relatório de glmark2 --validate para saber o nome do teste. Basta usar os nomes entre [ ], no início de cada linha.
Desta forma, para realizar o teste de refração, use o seguinte comando:

glmark2 --benchmark refract

Para rodar o teste de textura na resolução 4K (Ultra HD), use a seguinte linha de comando:

glmark2 --benchmark texture --size 3840x2160

Obviamente, se sua tela não tiver capacidade para exibir nesta resolução, a janela do glmark2 ficará um “pouco deslocada”. Mas é possível reposicioná-la com o mouse/touchpad.

Os resultados do glmark2

O glmark2 ainda não é a ferramenta completa para testes, uma vez que não cobre os recursos presentes nas versões posteriores ao OpenGL 2.0 — que já se encontra na versão 4.5 e deve começar a ser substituído pela nova API Vulkan.
Nos testes realizados, é possível ver uma progressão na contagem do FPS para cada teste, individualmente.
GPUs mais potentes são capazes de entregar taxas melhores de atualização.
Não confunda a taxa do FPS com a taxa de atualização do monitor (monitor refresh rate) que, provavelmente é 60 e não irá mudar.
O glmark não é capaz de oferecer resultados absolutos ou 100% conclusivos sobre a performance individual do hardware de exibição gráfica.

Uma máquina, por exemplo, com uma CPU de alto desempenho e sem qualquer peça de aceleração gráfica pode obter o mesmo resultado que uma outra máquina, com CPU + GPU medianas.

O motivo disto é que a renderização baseada em software, usada pela CPU de alto desempenho, equivale ao poder de processamento da combinação CPU + GPU de pequeno porte.
Esta é uma limitação do glmark2.
Fique à vontade para compartilhar com os outros leitores sobre o seu hardware gráfico e os seus resultados, na sessão de comentários.

Referências

Experimente também usar as ferramentas Unigine de teste de desempenho da placa gráfica.
Apesar de serem proprietárias, são excelentes.


OpenGL oficial page: https://www.opengl.org/about/.
Linux GPU benchmark: https://www.howtoforge.com/tutorial/linux-gpu-benchmark/.
http://www.binarytides.com/glmark-linux-gpu-performance/.

Uma explicação simplificada sobre a gestão de memória no Linux, com foco no swap.

Uma das coisas mais certas, quando se fala em gestão da memória RAM, é que não existe memória sobrando ou ociosa em um sistema Linux.
Cada aplicação usa uma quantidade da memória disponível no sistema.
Do que “sobra”, com exceção dos últimos megabytes, o Linux usa para fazer caching — no que se inclui o cache de página, os caches de inodes etc.
Ocupar toda a memória física disponível, é benéfico — ajuda a melhorar enormemente a eficiência geral do sistema.
Tanto a leitura quanto a escrita em disco podem se beneficiar imensamente com o uso do cache.
Em mundo ideal, você sempre terá memória suficiente para abrigar todas as suas aplicações, suprir as necessidades delas e, de lambuja, ainda terá algumas centenas de megabytes disponíveis para fazer caching.
Neste mundo utópico, desde que suas aplicações não façam demandas crescentes por mais memória e o sistema não exerça pressão crescente no cache, não há necessidade alguma para swap — a não ser permitir a hibernação.

Além de auxiliar na gestão da memória virtual do sistema, o swap tem outro papel importante: guardar o estado atual do sistema, caso você ative a hibernação do computador.
Esta função do swap não será abordada neste texto, já que não tem relação direta com o gerenciamento de memória do sistema.

Para se aprofundar mais em algum tema, clique nos links incluídos no texto deste artigo e nos que estão relacionados ao final do post.


Voltando ao caching
À medida em que as aplicações precisam de mais memória física, o sistema vai abrindo mão do espaço que estava usando para o cache em prol delas.
Desalocar cache é tão simples e fácil que é feito em tempo real.
Uma vez que todo o conteúdo do cache é sempre uma cópia de algo que já se encontra gravado em disco, portanto seu espaço, ou pode ser disponibilizado imediatamente, ou já está sempre prestes a ser liberado nos próximos segundos.
O fato é que realocar o espaço usado para caching tem zero impacto na performance das aplicações.
Tendo isto em mente, quando nos referimos a memória física “livre”, podemos estar incluindo ou não a que está sendo usada pelo cache.
linux-memória-ram-livre
Esta é a maneira como todos os sistemas operacionais modernos trabalham. Na hora de exibir a quantidade de memória livre, contudo, alguns incluem o que está ocupado pelo cache, outros não.
Concordo com alguns autores que, ao falar de “memória livre”, faz mas sentido incluir a parte ocupada pelo cache — já que é instantaneamente disponibilizada ao ser requisitada pelas aplicações.
No Linux, ao executar o comando free, ele exibe as duas situações:

free -h
              total        used        free      shared  buff/cache   available
Mem:           2,0G        207M        1,2G         55M        521M        1,7G
Swap:          6,7G          0B        6,7G

No Linux, o comando free, inclui valor do cache na coluna “disponível” (available).
Se preferir ver os valor do cache destacado em uma coluna, use as opções ‘-hwt’:

free -hwt
              total        used        free      shared     buffers       cache   available
Mem:           2,0G        491M        262M        127M        2,0M        1,2G        1,3G
Swap:          6,7G        144K        6,7G
Total:         8,7G        491M        7,0G

Como o Linux usa o swap

Este tópico será explicado de maneira básica, aqui.
Sugiro a leitura de Perguntas e respostas sobre o SWAP, caso você queira saber mais sobre o assunto.
Uma vez preenchida toda a memória física disponível na sua máquina, não há mais espaço suficiente para o cache garantir a velocidade do fluxo de dados entre as mídias físicas e a memória.
Neste caso, o Linux irá realocar espaço na memória, usado por aplicações inativas (ou pouco usadas), da memória RAM, para o swap (no disco rígido), com objetivo de ter de volta algum espaço para operar com o cache.
Isto não acontece como fruto de uma decisão simples. Não existe “um percentual” de uso da memória a partir do qual o sistema automaticamente começa a fazer swapping.
Há um algoritmo mais complexo envolvido, a partir do qual o Linux decide que é hora de levar dados da RAM para o disco.
O algoritmo leva vários fatos em conta. Este processo pode melhor ser descrito por “quanta pressão há para alocar novos bytes de memória”.
Se houver muita pressão para alocar novos blocos de memória, também haverá mais chance de que alguns outros blocos sejam “swapeados” para criar mais espaço na memória. Se houver menos pressão, as chances serão menores.
A variável que regula a pressão do cache (ou cache pressure), pode ser definida, junto com o swappiness“.
Se quiser saber como fazer isto, leia Como reduzir o uso do swap para melhorar o desempenho.
A menos que você saiba o que está fazendo, em computadores de uso genérico, não é recomendável alterar estas variáveis.
É comum vilanizarmos o swap. De modo geral, contudo, ele é uma coisa muita boa.
Você pode ser penalizado na performance do seu sistema, por uso ocasional do swap. Mas esta situação traz mais ganhos à responsividade e à estabilidade geral do sistema.
Ao reduzir o valor do swappiness, permite-se que a quantidade de memória cache diminua um pouco mais do que iria normalmente — mesmo que, de alguma forma, ela pudesse ser útil ao sistema.
O uso de valores baixos para a variável swappiness, traz o risco de tornar um computador (de uso genérico) mais lento — por que ele terá menos espaço para fazer caching.
Cabe a você determinar se, no seu caso específico, esta relação pode ser interessante e trazer ganhos de desempenho
Desabilitar completamente o swap, pode trazer riscos a estabilidade do seu sistema, principalmente se ocorrer de toda a memória física vir a ser ocupada.

O que acontece no sistema quando ele está atolado e fazendo uso pesado do swap?

Com alguma frequência, acontece de percebermos que nosso computador parece atolado de tarefas, super lento e o led indicador de atividade no disco está “quase queimando”.
Neste caso, aparentemente, o sistema está enviando uma quantidade tremenda de dados da memória RAM para o HD (ou SSD).
Culpar o swap pela situação, é uma maneira inadequada de abordar o problema.
Se o swapping realmente atingiu este extremo, o fato é que a memória física está prestes a se esgotar — e o swapping é justamente quem está evitando o travamento do sistema ou evitando que este saia “matando” processos a esmo, para conseguir se manter em pé.
Sem o swapping, numa situação como esta, processos irão colidir e morrer (crash n’ die).
Neste caso, o que se tem é um sintoma de problemas mais profundos.
Se o seu computador tivesse memória suficiente, para a execução de todas as suas tarefas, o espaço de troca (swap) serviria apenas para garantir que a memória fosse usada de forma eficiente.
Remover o swap ou restringir arbitrariamente seu uso não vai mudar o fato de que você tem um hardware com pouca memória física para executar suas aplicações.

Quase tudo do que se fala do swap e cache, aqui, vale para qualquer sistema operacional atual. Não se restringe ao Linux, portanto.

O Linux é um sistema operacional extremamente amadurecido e testado em condições das mais adversas (nos computadores mais exigidos do mundo, inclusive).
Acredite, o algoritmo que cuida da gestão da memória, escolhendo os dados menos usados para “swapear” pro disco, é muito eficiente — e a grande maioria dos usuários jamais irá precisar alterar suas variáveis e seus parâmetros de trabalho.
Em um sistema desktop, pouco usado, há uma situação bastante conhecida em que o usuário chega, após algum tempo em que a máquina estava sem uso, e tem que esperar alguns segundos (que parecem horas) até que se torne disponível novamente.
Esta demora é resultante do trabalho de mover de volta (do disco para a memória RAM) os processos que estavam ociosos.
Isto é comum quando deixamos a máquina ligada durante a noite, realizando alguma tarefa, como downloads, checagem antivírus, backup etc., enquanto dormimos.
De manhã, o sistema não tem como prever que você vai querer usar o navegador, que ficou inativo durante horas. Portanto, você terá que esperar um pouco.
Este é um dos pontos “chatos” de deixar o swap habilitado e por conta do sistema. Se você desabilitá-lo, esta lentidão, após o backup (por exemplo), não irá mais ocorrer. Em compensação, o sistema irá rodar um pouco mais lento, durante o uso diário — na medida em que haverá menos espaço para cache.
Outro fator a ser considerado, é a perda da proteção no caso de faltar memória física para suas aplicações — neste caso, o sistema vai arriar.

A maneira mais eficiente, em termos de custos, de resolver lentidão associada ao uso do swap pelo sistema, é aumentar sua memória física.
Se isto não for possível, avalie trocar suas aplicações por outras mais leves.
Desabilitar ou restringir o uso do swap é uma das soluções menos eficazes — uma vez que ele é apenas um mecanismo do sistema, usado para lidar com situações em que a memória física se tornou escassa.

Em sistemas com grande quantidade de memória RAM, o swap pode ser desabilitado com segurança?

Nos dias atuais (veja a data do post), 8 Gb de memória RAM é uma grande quantidade de memória — se estivermos falando de uma distro Linux comum, para uso genérico.
Neste cenário, raramente o usuário irá chegar ao ponto de precisar de swap.
Ainda assim, é desnecessário desativar o swap — lembre que ele tem outras utilidades.
Tampouco há necessidade de ajustar o swappiness — o sistema “sabe” que há bastante espaço na memória RAM para as aplicações e para o cache e nunca irá tomar a decisão de usar o swap.
Se, ainda assim, você quiser desabilitar o swap e reduzir o swappiness, o sistema continuará funcionando bem. Simplesmente não fará diferença.
Nos raros casos em que o sistema precisar lançar mão do swap, vai ser bom tê-lo à disposição.
Deixar os valores padrão, portanto, é a opção pela segurança e pela eficiência — tendo ou não uma grande quantidade de memória.

Como o swap atua para tornar o meu sistema mais rápido?

A transferência de dados entre a memória física e o swap (em HD ou SSD) é uma operação lenta.
Porém, é uma atitude que o kernel só toma quando tem certeza de que os benefícios superam seus custos.
Um exemplo disto é quando a aplicação ativa no seu sistema cresceu no uso da memória a ponto de não deixar mais espaço livre para o cache — ocasionando uma perda sensível na eficiência da transferência de dados.
Neste caso, há benefícios em mover porções inativas ou pouco usadas da memória para o swap, liberando alguma quantidade de memória suficiente para agilizar o fluxo de dados do cache.
Algumas aplicações podem também precisar de uma grande quantidade de dados na hora de iniciar. A pressão por recursos é aliviada logo após seu completo carregamento.
Se o seu sistema já estiver sobrecarregado, de antemão, o swap pode evitar um crash, durante este processo.

Conclusão

Não faça deste caso, um dilema Tostines.
Não é o swap que torna o seu sistema mais lento. É o contrário.
É por estar muito lento, que seu sistema faz uso deste recurso.

As pessoas associam a lentidão do sistema ao uso do swap, por que seu uso acontece quando o sistema está perto da inanição por recursos de memória.
O swap, antes de estar atrapalhando a sua vida, pode estar salvando o seu dia de trabalho.
Se ele está “salvando demais” o seu dia, em vez de fazer dele um vilão suas ações precisam ter como alvo o problema certo — a falta de recursos para rodar as aplicações atuais. Ou muda as aplicações, ou aumenta os recursos.

Referências

Como verificar a memória swap no Linux.
Como criar um arquivo swap no Ubuntu.
Perguntas e respostas sobre o swap.
http://askubuntu.com/questions/184217/why-most-people-recommend-to-reduce-swappiness-to-10-20

Como determinar a velocidade de seu memory card ou pendrive no Linux com o comando dd

Fazer uma análise do desempenho ou da performance de um dispositivo de armazenamento removível (cartão de memória, drive flash, pendrive etc) é bastante fácil.
Neste texto vou mostrar como usar o comando dd, como ferramenta padrão de qualquer distro Linux, para fazer um benchmarking nos seus dispositivos.
Este tipo de resultado pode ser interessante obter toda vez em que você precisar decidir qual dispositivo quer usar para instalar uma distro Linux Live, por exemplo — onde você vai precisar ter o máximo de desempenho.

A minha história é a seguinte: estou querendo revitalizar um dos meus notebooks antigos, que está sem o disco rigido.
Para isto, vou usar uma ou duas distribuições GNU/Linux Live rodando do pendrive ou do cartão de memória e vou optar por instalá-las nos dispositivos mais rápidos que eu tiver — ou, pelo menos, nos menos lerdos.
Os pendrives usados neste teste são antigos e a máquina conta apenas com 2GB de memória RAM.
Uma quantidade de memória RAM inferior a 3 GB é, na minha opinião, desestimulante para tentar rodar o Linux inteiramente na RAM — para isto, basta usar o parâmetro boot=toram na inicialização do GRUB, caso você queira tentar.
Se você tem também uma máquina antiga à qual gostaria de dar mais algum tempo de sobrevida (de 6 meses a 1 ano, ou mais… ), recomendo investir na compra de um drive em estado sólido SSD.
Além de ganhar velocidade, quando a máquina velha parar de funcionar definitivamente, você pode usar seu SSD em outra máquina.

Não esqueça de fazer backup completo dos dados armazenados nos dispositivos — os procedimentos descritos neste texto ocasionam perda de dados.
Seguem as descrições de cada metodologia usada.

Como determinar a velocidade de leitura e escrita de um dispositivo de armazenamento com o comando dd

O comando dd, no GNU/Linux é um dos comandos tradicionais. Vale a pena conhecê-lo melhor — trata-se de um “canivete suíço”, para realizar as mais variadas tarefas.
Quando terminar o teste, vou usá-lo para instalar as minhas distribuições favoritas dentro do pendrive — clique aqui, para ver como é fácil fazer isto.
O comando dd simplesmente copia dados de um lugar (indicado pelo parâmetro if=) para outro (of=).
Se você faz uso de um sistema de arquivos com caching, tenha em mente que este fator irá influenciar o teste e você poderá obter resultados irreais.
Para tentar driblar o cache, certifique-se de usar valores significativamente altos para o parâmetro ‘count’ do comando dd.
Isto irá forçar o sistema operacional a gravar os dados direto no dispositivo.
Minha sugestão é usar valores acima de 50Kb.
O teste com o dd consiste em enviar dados (aleatórios) para serem escritos direto no dispositivo conectado, com alguns parâmetros adicionados. Veja um exemplo:

sudo dd if=/dev/zero of=/dev/sdd bs=1M count=10241024+0 registros de entrada
1024+0 registros de saída
1073741824 bytes (1,1 GB) copiados, 229,927 s, 4,7 MB/s

Para o propósito deste post, a taxa de leitura do dispositivo terá mais impacto na performance.
Para obter a taxa de leitura sem a influência do cache, execute o seguinte comando antes de cada teste:

sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

Se quiser saber mais sobre o procedimento de limpar a memória cache no Linux, clique aqui.
Para testar a taxa de leitura, use qualquer arquivo dentro do pendrive em ‘if=’:

dd if=/media/pendrive/teste.log of=/dev/null bs=4k
51200+0 registros de entrada
51200+0 registros de saída
419430400 bytes (419 MB) copiados, 25,1704 s, 16,7 MB/s

Limpar o cache é opcional — mas, se você não fizer isto, vai obter uma taxa de leitura na casa dos GB/s, da qual você não irá usufruir na realidade.

O padrão USB 2.0 tem uma taxa máxima de 480 Mbits/s ou 60 Mbytes/s, teoricamente.
Em função de várias restrições, contudo, a taxa máxima de transferência acaba sendo 280 Mbits/s ou 35 Mbytes/s.
Além disto, a taxa de transferência vai depender da qualidade do seu dispositivo USB, além de outros fatores.

Como última dica, se você está testando cartões de memória para usar no Raspberry Pi e pretende usar aplicações/servidor de banco de dados MySQL ou PostgreSQL, use um blocksize = 8k. Assim:

dd if=/media/pendrive/teste.log of=/dev/null bs=8k