ZSWAP em Sabayon Linux. Continuação. Testando a ZSWAP Controlável.

Autoria de Alberto Federman Neto, albfneto

A – INTRODUÇÃO:

Em meu Artigo Anterior, 1:

ZSWAP em Sabayon Linux. Controlável, “Ligável” e “Desligável”.

Mostrei como pode ser instalada a ZSWAP Controlável.

Agora, vamos realizar os Testes…

 

B – PRÉ-REQUISITOS DE HARDWARE E SOFTWARE:

Consultando o Artigo Anterior, Sessão C, verá o hardware utilizado.

Verá também que para uniformizar as condições dos testes, instalei e rodei no micro, dois pacotes aceleradores: O “carregador” de aplicativos na RAM preload (mantive a Swap de disco) e o “controlador” de memória de processos, Verynice.

Como vamos testar, nas mesmas condições, precisamos ter certeza de que esses pacotes estão rodando. Se você não os tiver, instalados, instale agora:

$ sudo equo i -av preload verynice

Como a idéia é mesmo testar uma variante “desligável” de swap, podemos rodar esses aceleradores, não como serviços de boot, e sim como processos.

Aproveitando os ensinamentos  e Scripts (como base) dos meus amigos do VOL:  Arthur Roch ,  Marcelo Oliver  e Listeiro 037, fiz mais um Shell Script simples, que ativa o Preload e o Verynice.

Após a instalação dos pacotes, prepare o Script (se não souber como se faz, consulte o Artigo Anterior, 1, Sessão E).

Para fazer o Script, use este Código:

#!/bin/bash

# Script Acelerador de Computador.
# Carrega  os pacotes Verynice e Preload,
# e os mantém rodando.
# Autor: Albfneto, Brasil, 2016. <albfneto@fcfrp.usp.br>
# Feito baseado em outros Scripts de:
# Arthur_Hoch, MsOliver e Listeiro_O37.
# https://edpsblog.wordpress.com/2016/07/29/zswap-em-sabayon-linux-
# controlavel-ligavel-e-desligavel/

 
# Checa Sudo:
 # Esta porção do código, modificada do publicado por: Braiam, 2015.
# Site: askubuntu.com/questions/711580/how-to-enter-password-only-once-in-a-bash-script-needing-sudo
if [[ $EUID -ne 0 ]]; then
   echo "Este Script precisa ser executado como Root, porisso use: sudo sh "$0""
   1>&2
   exit 1
fi

# Função Print:
 print(){
       echo -e "\n\n$1\n\n"
       if [ ! -z $2 ]; then sleep $2; fi
  }
# Mensagens Iniciais
print "ACELERADOR..."
print "Script Acelerador de Computador." 
print "Carrega Preload e Verynice"

# Carregando Preload:
# Preload é "Daemonizado", mas mesmo assim, comando para
# manter sua execução:
preload &
sleep 4
print "Preload Carregado..." 
sleep 2
ps ax | grep preload
echo

# Carregando Verynice:
sleep 4
# Ativando o Verynice, comando planejado para manter sua execução
# após fechado o terminal:
verynice &
sleep 2
print "Verynice Carregado..." 
echo
ps ax | grep verynice
echo

 print "Ambos os Aceleradores Carregados"
 print "Pode fechar seu Terminal, os aceleradores continuarão rodando"
  print "Tô saindo, Tchau"
 sleep 4 
 exit 0

E salve com um nome, por exemplo, acelera.sh

Feito o Script, execute-o como Root, com este comando:

$ sudo sh acelera.sh

Note que no meu caso, salvei o Script na mesma pasta da ZSWAP, a zram-utils. Se quiser facilitar, como eu fiz, crie nessa pasta  um Atalho tipo Desktop, para executar o Script, e coloque nele estas linhas:

[Desktop Entry]
Exec= sudo sh acelera.sh
GenericName[pt_BR]=Acelerador
GenericName=
Icon=im-gizmo
StartupNotify=true
Terminal=true
TerminalOptions=
Path=~/Desktop/PACOTES/zram-utils/
Type=Application 

Atenção para o caminho, o PATH. Você precisa modificar, dependendo da pasta onde gravou o Script acelera.sh.

Salve o Script por exemplo como Acelerador.desktop. Clicando duas vêzes no Atalho, um terminal se abrirá e o Script acelera.sh será executado. Dependendo do tipo do seu Terminal, ele pode fechar automáticamente após a execução. No meu KDE, o Konsole fecha.

O Script foi feito de um modo que os processos do Preload e do Verynice continuam ativos.

O Script carregará os pacotes Preload e Verynice e mostrará que estão carregados e que os processos estão rodando.

Aqui vejam o Script, o Atalho. Também o Script rodando:

Script e Atalho para Ativar Preload e Verynice. Script Rodando.

No meu caso (veja acima) trabalhei com preload e verynice ativados, mas se quiser desativar, “mate” os processos deles, com os comandos:

# killall preload
# killall verynice

Para facilitar, todos os Scripts, este e os para ligar e desligar a ZSWAP, Software zram-utils, Atalhos de Teclado, Scripts rascunho, tanto para este como para o outro Artigo, podem ser baixados prontos, do Pastebin do Sabayon.

Estamos prontos para começar a testar.

C –  SOFTWARE, PACOTES, CÓDIGO, USADOS DURANTE OS TESTES:

Foram instalados os pacotes: Gkrellm, Hardinfo , CPUBurn, Stress,  HTOP :

# sudo equo i -av gkrellm hardinfo cpuburn htop stress

Gkrellm é um bonito Monitor para KDE. Foi usado para monitorar temperaturas, RAM etc….

Hardinfo é um bom pacote gráfico, que traz as características do seu hardware e tem embutido uma suite de “benchmark” simples, que foi rodada para avaliar a performance.

O Everest do Linux.

Obtendo Especificações do Computador.

Verificação de Hardware com Hardinfo.

CPUBurn , Stress  e CPUBurn-In, são pacotes especiais, usados para estressar CPU, fazê-la funcionar ostensivamente, consumindo os recursos da CPU e a RAM de todos os núcleos.

HTOP é um pacote, um melhoramento do comando top. Mostra os processos em execução, quanta memória gastam, e outras informações.

Ainda, iremos executar uma Fork Bomb clássica. Fork Bombs são pequenos comandos na Shell, no Bash, ou pequenos programas em diversas linguagens,  capazes de gerar um processo que se auto-executa  e auto-replica, gastando toda a RAM do micro, até travar.

Para a segurança do sistema, porém, vou interromper, “matar” o processo antes disso.

Todos os testes  foram feitos no “Sabayon de Testes” (Veja Ítem B e Artigo 1 e Artigos citados), interface gráfica KDE5, em condições de partição Swap normal:

Criando e Aumentando Memória Virtual ( SWAP) no Linux .

Administrando Memória Swap no Linux.

e também com a ZSWAP ativada em todos os núcleos (Veja como no Artigo 1), para fins de comparação.

# modprobe zram num_devices=8

D – RESULTADOS DOS TESTES:

D 1- CPUBurn

Com a Swap clássica, rodei o comando:

$ burnK7

O uso da CPU vai a 100% rápido, mas em cada núcleo, dá só uns 21%. Também a Swap, vazia. O micro é tão grande e tem os 16 Giga de RAM. Daria para rodar muita CPUBurn….

vejam na Figura, Notem os Monitores:

CPUBurn, com Swap Normal.

Vamos ver agora, ativando a Zswap em todos os núcleos (Veja Artigo 1) Note que em Teoria, temos até 95 Giga de RAM:

ZSWAP Ativada, em todos os núcleos.

Rodando o CPUBurn. Olha, estressa a CPU, esquenta um pouco, mas não usa muita RAM, e nada de Swap, nem a ZSWAP.

Isso indica que CPUBurn nada tem a ver com A RAM, nem a SWAP.

Resultados muito parecidos, obtidos com e sem  ZSWAP ativada. Totalmente comparáveis! E no caso do meu micro, esse Phenom, ele aguenta muito processamento…

D 2 – Stress:

Agora vamos ver com o pacote Stress, da Universidade de Harvard.  Swap clássica.

Usei opções parecidas com as recomendadas, apenas modificadas para meus 8 núcleos e aumentadas:

% stress --cpu 8 --io 4 --vm 1 --vm-bytes 32G --timeout 45s --verbose

Usei CPU para os 8 núcleos, IO 4, VM 1 (só uma swap) , tamanho dela 32 Giga (minha swap tem o dobro da RAM) e rodei por 45 segundos, para dar tempo de capturar a tela.

Os núcleos vão a 100%, todos, a RAM quase toda usada (sobram uns 1.4 Giga) e 2-4 Giga da Partição Swap são usados. O que é muito usado é a GPU (processamento de vídeo), tanto é usado, que o micro ficou muito pouco responsivo. Mas roda (45 s), sem práticamente esquentar. Pude prolongar até 120 s, e vai!

Rodando pacote Stress, Swap Clássica.

Mais interessante ainda quando se roda o pacote Stress, com a ZSWAP ativada.

O comando é parecido, mas adaptei para os 95 Giga teóricos e os “8 núcleos +swap”… 9…

$ stress --cpu 8 --io 4 --vm 9 --vm-bytes 95G --timeout 45s --verbose

Agora usa toda a RAM, sobram uns 300 Mega,

e usa até  uns 35, 40 da Partição Swap + ZSWAP: (dos 95). Mas não trava, e fica mais responsivo do que sem a ZSWAP ativada….

Vejam, notem o monitor Gkrellm… veja como o sistema usa a Swap e a ZSWAP.

Usando o pacote Stress, com a ZSWAP Ativada. Alto consumo de RAM e de Swap-ZSWAP.

Como o pacote stress foi muito eficiente para “gastar” a RAM , a Swap e a ZSWAP do micro, fiz mais um teste:

Abrí três terminais…. no primeiro, à esquerda, o comando do Stress roda (mesmos comandos acima); No segundo terminal do meio, HTOP para ver os processos; no terminal da direita, o comando “free -th” mostra a RAM e a Swap total.

Vejam na figura, com a ZSWAP “desligada…. A RAM é usada e a partição Swap, também, bastante. Práticamente nada sobra da RAM do micro….

Teste de Stress. Sem ZSWAP. RAM e partição de troca muito usadas.

Para ver os processos rodando e consumindo memória, uma Dica de um outro bom comando seria:

$ ps aux | sort +2 -nr

Depois repetí o teste, com a ZSWAP “ligada”.

Não foi possível capturar a tela, pois o micro ficou muito pouco responsivo…. mas vejam abaixo, parte da saída do comando “free -ht” mostrando consumo da RAM (quase toda) e muito da Swap e da ZSWAP:

PACOTE stress, COMANDO USADO,  CPU 8 NÚCLEOS, EM TEORIA 9 NÚCLEOS DE MEMÓRIA (1 SWAP E 8 ZSWAPS)TEÓRICOS 95 GIGA:
$ stress --cpu 8 --io 4 --vm 9 --vm-bytes 95G --timeout 45s --verbose

NO HTOP, MOSTRADAS VARIAS INSTÂNCIAS DE UM MESMO PROCESSO

AQUI O COMANDO free -ht. VEJA QUE A SWAP + ZSWAP, MUITO USADAS. RESTAM 31 G, DE 95 G (TEÓRICOS, NA PRÁTICA 92).
DA RAM DO MICRO, SÓ RESTARAM 131 M:
free -ht
              total        used        free      shared  buff/cache   available
Mem:            15G         15G        131M        2,2M        175M        2,0M
Swap:           92G         31G         61G
Total:         108G         46G         61G

 

D 3 – Fork Bomb:

Rodei também esta Fork Bomb clássica:

Travando qualquer Máquina Linux.

Corrigindo esta falha de segurança no Linux

Com Swap clássica… e como funciona!

O Gkrellm fecha sozínho, a interface do  KDE Plasma, também, e fica lento….

gasta toda a RAM  (16 giga) e toda a partição Swap (32 Giga)… com 20 a 25 segundos, precisei correr…. fechei o terminal, a sessão e resetei o micro para descarregar a RAM. Foi impossível capturar o Screenshot…. Meu micro ficou “burrinho”, sem nenhuma memória….!

Já com s ZSWAP ativada, também parece que vai travar, o Gkrellm também fecha, mas o ambiente KDE, embora fique pouco responsivo, não trava, nem fecha. Pude ficar quase um minuto vendo rodar, mas também não consegui capturar a tela,

Ou seja, parece que também a ZSWAP ativada deixa sobrar mais RAM teórica para a Fork Bomb rodar.

D 4 – Hardinfo:

Com o pacote Hardinfo, não foi possível observar quaisquer diferenças significativas, nem com a ZSWAP ligada, ou desligada. Isso em todos os testes de Benchmark embutidos no pacote.

De fato, observei que os resultados são completamente iguais. Ainda, pude ver no Monitor Gkrellm , que sequer o Hardinfo consome a partição de Swap Normal, quem dirá a ZSWAP.

E – RESUMO E CONCLUSÕES:

Neste Artigo, a ZSWAP “Controlável”, “Ligável” e “Desligável” foi testada no Sistema Operacional Sabayon Linux, 16.08, “Partição de Testes”, deste Computador.

Foram usados os pacotes “estressadores de CPU” cpuburn e stress, bem como o pacote Monitor de Hardware Hardinfo (este para testes de “benchmark”).

Os Resultados demostram que a ZSWAP pode ser ligada e desligada, e sob o efeito dela, muito mais “RAM virtual” fica disponível para os processos, além da partição de Swap normal que o micro tem (32 Giga, o dobro da RAM).

Sôbre a perfomance, pude notar que ela aumenta quando a ZSWAP é “ligada”, mas no uso normal. Em micros com pouca memória, podem haver diferenças. Por outro lado, meu único micro com 1 só Giga de RAM no momento, é um Notebook com OpenSUSE, que não é só meu (Artigo submetido ao VOL), porisso não posso fazer testes nele

Quando rodo pacotes estressadores (principalmente o Stress, muito eficiente para “gastar” a RAM, a Swap e a ZSWAP), o micro fica pouco responsivo, Isso tanto com a ZSWAP ligada, como desligada.

Essa pouca responsividade torna difícil avaliar a diferença de performance com precisão, mas são condições extremas, que não invalidam os testes, pois nos monitores e comandos, vê-se claramente a RAM consumida, a Swap quase toda consumida e quanto disponível, até mais da metade da ZSWAP também é consumida.

O pacote Hardinfo não me deu resultados conclusivos, os benchmarks são iguais, os resultados, tanto com a ZSWAP “ligada” como “desligada”. De fato, notei que não há uso da partição Swap normal, quanto mais usar a memória virtual da ZSWAP.

Procurei na Internet por um Teste de Benchmark específico para RAM. Os encontrei, mas apenas para Windows:

BenchMarkHQ.

MaxxMEM.

CPU-M.

Ou programas pagos, para Linux:

AIDA64.

PassMark.

Observação: Ví também, nos testes, que como meu Script “desligador” da ZSWAP, restaura a partição Swap Normal, não há necessidade de “apagar” os dados na Swap e nem da ZSWAP.