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.088 ]

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

Varredura bruta com NMAP

Backups com TAR e DUMP

Redes definidas por Software com Mininet e POX - Criando meu primeiro Controlador

Alta disponibilidade com CARP

Melhorando o nível de segurança com chflags

Leitura recomendada

Plugins, Atalhos e Comandos do Visual Studio Code

Usar, usando

Antergos - Um caminho para conhecer o Arch Linux

Necessidade do profissional de informática

Nmap - 30 Exemplos para Análises de Redes e Portas

  
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