Archive for June, 2008

Metas 2008.. como estão?

Tuesday, June 10th, 2008

Bom em 2008 eu prometi muita coisa como no post que fiz neste blog.

Assim só atualizando as metas e algumas concluídas.. vamos lá:

  1. Manter o blog atualizado com how-tos e afins para a comunidade; = Não está como gostaria mes estou mantendo.
  2. Arrumar meu cantinho, porque hoje moramos na casa de minha mãe; = Consegui alugar um barracão no qual estou morando com a Dandy e já montei o meu escritório. Posto fotos depois.
  3. Passar no vestibular, e terminar um curso superior; = Estou fazendo facul, isso mesmo na COC
  4. Colaborar sem falhar com os pacotes e traduções no Debian; = PENDENTE
  5. Manter-me mais estável em um emprego. = Estranho falar isso mas estou quase completando um ano em uma única empresa, pois adorava ser mochileiro pelos desafios que me eram apresentados. Mas ficando quietinho um pouco estou podendo economizar e poder investir um pouco em mim e na minha família.

Agora convido a você a rever suas metas que a blogar como estão indo após 6 meses de luta.

Você sabe como estão os pacotes de sua arquitetura?

Tuesday, June 10th, 2008

Recentemente navegando no blog do nosso amigo Tadeu Pena ele postou falando sobre a situação dos pacotes que se encontram para quem usa o SID.

Achei interessante em repassar o artigo dele porque eu não conhecia esta parte do projeto Debian. Você que usa o SID sabe do que estou falando quando damos aquele famoso upgrade, e não conseguimos mais manter a nossa máquina “usável”. Assim pelo que entendi no site dos Desenvolvedores do Debian o “TEMPO” lhe indicará como está a situação daquele dia para os pacotes em sua arquitetura. Um tanto curioso mas muito interessante para aqueles que sempre gostam de ter a ultima versão do pacote em seu desktop instalado ;)

… “O “tempo” de uma determinada base de distribuição Debian é uma indicação de quão seguro é em um determinado dia para tentar fazer alguma instalação / atualização de pacote. Um “mau dia” é um dia em que uma percentagem razoável de que a distribuição e/ou repositório não é instalável devido a quebra e inter-dependências de pacotes. Um “bom dia”, ao contrário, é quando a maior parte (possivelmente todos) dos pacotes disponíveis nessa distribuição repositório serão instalados. ” … (tradução do texto do site)

Para aqueles que já estão se preparando para migrar o servidor de etch para lenny, é interessante visitar antes para ver se a arquiterura está num bom dia.. sem as famosas nuvens aterrorizantes :-D

No mais espero que tenham gostado que nem eu gostei.

Teste de Stress

Monday, June 9th, 2008

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.

Bad Behavior has blocked 14 access attempts in the last 7 days.