Tag Archive

for each ping do a reverse dns lookup

Em conversa com um colega ele referiu que quando temos de gerir servidores de 50000 clientes a experiência é melhor do que gerir 20, achei um comentário no mínimo, mínimo. Conheço mais 3 administradores de sistemas bem capazes cujo número de clientes não deve chegar aos 100 e no entanto o empenho e atenção aos detalhes permite-lhes sempre encontrar a melhor solução, se ela funciona sobre maior stress ou não isso já vai dos tweaks que tudo necessita à medida do crescimento.

Pessoalmente acho que a capacidade de responder a 36000 clientes ou 20 depende da máquina, solução e configuração, altera-se pouco nessas situações minimamente aliás(tudo depende de quem desenhou a arquitectura), a realidade é que parte da diferença entre trabalhar com 36000 clientes vs 20 encontra-se no tempo de resposta e resolução de um problema, por consequência o recurso aos nossos conhecimentos para a sua resolução. Os conhecimentos ditam o resto.

Como meço o meu desempenho e qualidade ?! Aponto um Nº de tarefas a executar a longo prazo+tarefas paralelas+nº de interrupções, comparo com o resultado dos vários servidores ( disponibilidade ) a este conjunto acrescento a minha capacidade de “prever” problemas e prevenir contra os mesmos (cada vez mais difícil) malditos updates.

Neste momento está no geral mais ou menos assim:

~10  , 2 dependem inteiramente do facto de estarem ambos operacionais e aí está 90% do problema que ainda estou a resolver. 10% do problema encontra-se de não ter nem nunca irei ter hardware que tenha capacidade para lidar com redundância de filesystems (porn is higly scalable, business data is not). Alternativas existem e aqui pode-se dizer que os comentários são muitos. Ter algo dependente apenas de um server é algo que abomino mas em certos casos tenho de viver com isso devido às alterações que seriam necessárias aplicar entre as várias “interfaces” que comunicam. A afectar isto tudo existe o custo de equipamento que define a direcção a tomar (not my problem).

Posso também dizer que a melhor altura para fazer “melhoramentos” é quando está tudo uma merda não existe um lado negativo apenas o positivo pois quando na merda qualquer passo que se tome para sair dela é um melhoramento.

O tempo de reacção em situações de stress é algo crítico aqui surpreendo-me ao afirmar que o tenho controlado mas o facto de ter alertas e vários dados para recorrer quando algo falha, diminui o meu tempo de reacção, o facto de já ter lidado com o mais variado tipo de situações reduz ainda mais o tempo de reacção. Ainda demoro um pouco a escrever bash scripts…

Quanto mais clientes mais experiência ? Não. Por vezes 10 clientes com um serviço que precisa  estar allways on, é muito mais exigente e reclama a qualquer problema do que um outro que não tem tanta necessidade do serviço, por isso o número de clientes é variável.

O mais importante que aprendi até hoje é que o load average não é proporcional ao uso de cpu e nunca fazer alterações quando em estado zombie ( apenas 2 horas de sono ) faça o que se fizer vai dar merda é uma questão de tempo. Lado positivo em estado zombie não existe sentimento de stress apenas uma leve chatice.

O mais inútil que aprendi é que … Não existe nada de inútil na vida.

O que eu gostaria era poder alterar a configuração de um monte maganos que andam por aí e à custa deles temos de andar com hacks.

Um factor importante é o tempo se o problema ocorreu às 22h52 foi às 22h52 e não às 22h53 !
A minha shell é assim:

[03:36:53] andre@linux-wii:~$

São 3h18m hoje não trabalho ia a Lisboa e a viagem acabou por ficar sem efeito mas tenho de acordar às 4h da manhã.

Included in Red Hat Enterprise Linux 4 are four custom configured schedulers from which to choose. They each offer a different combination of optimizations.

The Completely Fair Queuing (CFQ) scheduler is the default algorthim in Red Hat Enterprise Linux 4. As the name implies, CFQ maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. CFQ is well suited for mid-to-large multi-processor systems and for systems which require balanced I/O performance over multiple LUNs and I/O controllers.

The Deadline elevator uses a deadline algorithm to minimize I/O latency for a given I/O request. The scheduler provides near real-time behavior and uses a round robin policy to attempt to be fair among multiple I/O requests and to avoid process starvation. Using five I/O queues, this scheduler will aggressively re-order requests to improve I/O performance.

The NOOP scheduler is a simple FIFO queue and uses the minimal amount of CPU/instructions per I/O to accomplish the basic merging and sorting functionality to complete the I/O. It assumes performance of the I/O has been or will be optimized at the block device (memory-disk) or with an intelligent HBA or externally attached controller.

The Anticipatory elevator introduces a controlled delay before dispatching the I/O to attempt to aggregate and/or re-order requests improving locality and reducing disk seek operations. This algorithm is intended to optimize systems with small or slow disk subsystems. One artifact of using the AS scheduler can be higher I/O latency.

http://h71028.www7.hp.com/enterprise/cache/433096-0-0-0-121.html

Como diria um colega meu “NICENESS”