Blog do Sene

Chegou hoje na empresa no qual trabalho uma placa mãe que de cara eu tinha falado que tinham tomado cano, porque cade o processador. Aí a anta aqui não tinha lido sobre a era da família VIA, que agora tá correndo em carreira solo. Assim para que conheçam um pouco a placa é uma PC2500E.

Fui delegado em fazer os testes para ver se o produto que estão desenvolvendo rodaria neste tipo de computador e lá vou eu pro meu fundo do baú de comandos no debian e lembrei do stress.

Stress é uma ferramenta que pode ser configurada para realizar um testes de stress de CPU, I/O, memória e disco em sistemas da família unix. E sua licença é GPL.

Esta ferramenta foi desenvolvida para vários sistemas operacionais, como dito acima. Assim, existem compilações específicas para determinados sistemas e, também, existe o source code disponível para compilação local.

A instalação no debian é bem simples:

<code>aptitude install stress </code>

IMPORTANTE: Antes de realizar os testes, tenha no mínimo dois terminais abertos no servidor sobre teste. Assim, caso a ferramenta consuma muitos recursos da máquina, você terá a oportunidade de matar seu processo sem ter que esperar que o teste acabe. Caso esteja remoto como foi o meu caso use o screen.

Abaixo seguem alguns exemplos práticos de como testar o seu servidor com esta ferramenta:

<code> # stress --cpu 1k  </code>

Este comando faz um fork de 1024 processos a serem processados pela CPU.

<code> # stress --cpu 12 --timeout 10s </code>

Este comando faz um fork de 12 processos a serem processados pela CPU e o tempo do teste deverá ser de 10 segundos.

 <code> # stress --vm 2 </code>

Faz um fork de 2 processos que alocarão memória do servidor

<code> # stress --vm 2 --vm-bytes 128M </code>

Faz um fork de 2 processos que alocarão 128M cada durante o processo de stress test.

<code> # stress --vm 2 --vm-bytes 128M --vm-hang --timeout 1h  </code>

Durante o teste serão alocados 128Mb de memória do servidor que somente serão liberados ao término do processo (após uma hora, segundo o parâmetro “–timeout 1h”)

<code> # stress --io 4 </code>

Durante o teste, 4 processos farão múltiplas chamadas da função sync() (chamada de sistema que faz um flush do que existe na memória para o disco).

 <code> # stress --io 4 --timeout 10s </code>

Faz exatamente o que o teste acima faz, porém, durante apenas 10 segundos.

<code> # stress --hdd 6  </code>

Faz com que 6 processos utilizem a chamada de sistema write(), responsável pela escrita em disco no sistema operacional.

 <code> # stress --hdd 10 --hdd-bytes 2g --timeout 50s  </code>

Faz com que 10 processos utilizem a chamada de sistema write() para escrever arquivos de 2Gb de dados em disco, durante 50 segundos. O padrão para o parâmetro –hdd-bytes é de arquivos de 1Gb.

 <code> # stress --hdd 3 --hdd-noclean </code>

Faz com que 3 processos criem arquivos de 1Gb (default do stress) no ambiente e não façam o unlink destes processos. Para maiores detalhes a respeito do unlink, por favor, utilize “man unlink” em ambientes Unix.

Referência

Em http://weather.ou.edu/~apw/projects/stress/ podem ser encontrados mais detalhes a respeito do stress e suas formas de uso.

Muita gente ainda tem medo de acessos remotos em sua empresa e ao mesmo tempo as informações confidenciais serem roubadas. Mas o mercado vem mudando assustadoramente, até mesmo com ensino superior a distância, por coincidência estou fazendo também (coc).

Alguns clientes fazem contratos para acesso remoto, e aí? as horas trabalhadas são enviadas na base de confiança?

E aqueles que querem que comprovemos?

Eu tinha me esquecido do comando que poderia responder a este problema, mas fazendo uma breve e muito rápida a pesquisa encontrei o:

# last

Este comando apresenta tudo que necessitamos para a comprovação de nossos acessos aos servidores:

User Terminal Sem. Mês Dia Hora Inicial Hora Final Total de horas logada

sene pts/0 :0.0 Fri Feb 1 14:22 – crash (00:59)
sene pts/3 :0.0 Fri Feb 1 13:50 – 13:54 (00:03)
sene pts/2 :0.0 Fri Feb 1 13:45 – 13:54 (00:08)
sene pts/1 :0.0 Fri Feb 1 10:59 – 13:54 (02:54)
sene pts/0 :0.0 Fri Feb 1 10:15 – 13:54 (03:39)
sene tty1 Fri Feb 1 10:14 – crash (05:07)
sene tty1 Fri Feb 1 10:14 – 10:14 (00:00)
sene pts/0 :0.0 Fri Feb 1 10:11 – down (00:01)

Uma solução prática hoje pra mim

Hoje troquei minha máquina de trabalho de i386 para amd64, assim me deparei com algumas falhas de programas que necessitamos no dia a dia de trabalho. Ainda mais que tenho que sempre ficar on-line com os famosos softwares: skype, gajim (jabber, talk, msn, yahoo, icq, entre outros).

Para estes tive que fazer somente um malabarismo com o skype, pois o restante tinha no repositório oficial do debian. Já a nível da navegação tive problemas com o firefox, parei um pouco para debugar o script de instalação e consegui instalar o mesmo do site oficial sem muitas torturas… assim posto a simples linha que devem alterar.

Baixe no site da Macromedia o tar.gz do flash.

Como usuário normal, sem ser root, descompacte-o e entre no diretório:

[sourcecode language='bash']$ cd ~/install_flash_player_9_linux[/sourcecode]

Agora edite o arquivo de instalação:

<pre lang=”php”> $ vi flashplayer-installer</pre>

Procure por este pedaço do código:

<pre lang=”php”> # check architecture
TEMPARCH=`uname -m`
case $TEMPARCH in
i[3456]86)
ARCH=i386
;;
*)
exit_cpu $TEMPARCH
;;
esac</pre>

Altere somente este pedaço:

<pre lang=”php”> # check architecture

TEMPARCH=`uname -m`
case $TEMPARCH in
#i[3456]86)
x86_64)
ARCH=i386
;;
*)
exit_cpu $TEMPARCH
;;
esac</pre>

Pronto agora só instalar normalmente, lembre-se todos os browsers que tiver aberto deverá estar fechando antes da instalação, agora só rodar o comando:

<pre lang=”bash”>$./flashplayer-installer</pre>

Para ter certeza que funcionou, abra o browser e digite about:plugins se aparecer o flash esta tudo ok.