Esgotando os recursos

Este artigo não tem a intenção de esgotar o assunto e sim auxiliar os novos administradores de sistemas a verificar recursos em nível de hardware. A motivação parte daqueles que, de forma desnecessária, solicitam upgrade de hardware, onerando as instituições que trabalham ou tem seus servidores carroçando, mas não sabem qual o motivo específico da lentidão. Para teste foi usado o FreeBSD RELENG 7.2 RELEASE.

[ Hits: 23.081 ]

Por: cristofe coelho lopes da rocha em 21/01/2010


Evitando vexame :-(



Este artigo não tem a intenção de esgotar o assunto e sim auxiliar os novos administradores de sistemas a verificar recursos em servidores. A motivação parte daqueles que, de alguma forma, solicitam hardware de forma desnecessárias, onerando as instituições em que trabalham e/ou tem seus servidores carroçando, mas não sabem qual o motivo específico da lentidão.

Para realizar os testes foi utilizado o sistema FreeBSD RELENG 7.2 RELEASE padrão, ou seja, sem nenhuma customização.

Antes de tudo é importante conhecer o seu hardware e a tarefa que ele irá executar. Todavia, a cada implementação nova seu servidor pode reagir de forma inesperada ou no mínimo diferente. Caso o servidor tenha um número de conexões acima do normal, como poderíamos saber qual dos recursos de hardware que preciso melhorar? Ou até mesmo que processo devemos otimizar? Isso mesmo, pois o fato é que muitos administradores tem incrementado os orçamentos de T.I nas instituições pelo simples fato de não conhecer o sistema que administra.

Um grande amigo meu que administra redes em um dos locais em que trabalho teve seus recursos de T.I limitados em função destas coisas quando percebi que tomaria uma decisão para virtualizar alguns processos. Na ocasião era necessário verificar qual servidor poderia ser utilizado para a tarefa e observei que não tinha o conhecimento necessário. Acredito que este artigo será bastante útil não só para ele, assim como para os demais que estão nesta situação. Se você não quer ser passar por este vexame pode ler este artigo. Será muito útil para alimentar seu relatório.

    Próxima página

Páginas do artigo
   1. Evitando vexame :-(
   2. Verificando o limite de disco
   3. I/O Status
   4. Status geral
Outros artigos deste autor

Fingerprint: Conhecimento TCP

Um dia depois da inundação

Festa com SQL injection

Alta disponibilidade com CARP

Backups com TAR e DUMP

Leitura recomendada

Porque migrar para o Linux - No meu caso também, preguiça

openSUSE Argon

CD repositório para o aptitude

Escritório 100% GNU/Linux: viável e econômico

OpenLDAP: Instalando um servidor de diretórios com replicação (SyncRepl)

  
Comentários
[1] Comentário enviado por ffranca em 21/01/2010 - 18:46h

Olá muito legal o seu artigo, poderia modificar a opção do df para "df -h" o h seria de leitura humana.

[2] Comentário enviado por cristofe em 24/01/2010 - 16:01h

Muito bem, Ffranca, agradeco pela contribuicao. Lembrando que recurso tipo: TOP PS também são bastante interessante, para evitar dúvidas se o problema será de Hardware ou algum processo que esta requerendo muito recurso. Abraço

[3] Comentário enviado por cristofe em 24/01/2010 - 16:03h

Muito bem, Ffranca, agradeco pela contribuicao. Lembrando que recurso tipo: Informações do tipo Uptime e cpu e mem podem ser aqdquiridas com o TOP e PS. São bastante interessante, para evitar dúvidas caso o problema seja Hardware ou algum processo que esta requerendo muito recurso. Abraço

[4] Comentário enviado por cytron em 25/01/2010 - 01:57h

procinfo também é útil, muito bom mesmo, mostra memória (free), data e hora do boot, carga média do sistema, algumas outras coisas e até uso de irq.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts