[silas_i]

Estive batendo um papo com um amigo sobre o que fazer quando o servidor começa a ficar com o Load Alto. Pra minha surpresa ele assim que o server começa a ficar alto (load) ele reinicia o servidor que está sobrecarregando o servidor. Não acho que este seria o certo, mas gostaria de ouvir o que vocês fazem quando o server começa a ficar com o Load Alto. Eu por exemplo: Analiso os logs, tentando verificar o que está ocorrendo, se for algum ataque tento bloquear o IP, mas e nos casos de grandes quantidades de acessos ao apache, emails ou mysql ? Você reiniciaria o serviço ?

[Martinewski]

Acho essa suposta solução de reiniciar o serviço algo grosseiro. Além de matar os processos que estão em andamento, ou seja, prejudicar quem está acessando naquele momento, esta não é a solução. Se as requisições continuarem (provável) o load aumentará novamente, pois algo não está bem equacionado: hardware ou software.

O que quero dizer com isto é que ou o equipamento não é suficiente para a demanda ou as configurações do servidor não estão bem ajustadas, ou ainda o cliente não está com o site/serviço otimizado.

Acredito que este tripé seja essencial para altas demandas. Hardware adequado, servidor e software do cliente otimizados.

Tenho um blog (Wordpress) hospedado no meu servidor que esta semana teve um boom de acessos e fez o load do servidor subir o load de 5min acima de 5.0. Recebi alerta um dia e não fiz nada. No segundo dia recebi dois alertas. Vi que os acessos vinham subindo constantemente e que o php estava consumindo e ficando com alguns defunct. Então junto com o dono do site instalei um plugin de cache no Wordpress. Aparentemente resolveu. Precisei do entendimento do cliente para que o problema fosse ajustado.

Se eu simplesmente passasse a reiniciar o Apache, as próximas visitas iriam aumentar o load novamente. Na minha opinião isso é genérico, ou seja, serve para quase todas as situações e cenários.

[Juliano P]

Reiniciar o serviço é uma solução paliativa. Vou dizer por que USO esta opção:

1) se o gargalo for memória RAM, quanto mais RAM for sendo consumida, mais o load vai aumentar, pois ele vai começar a usar SWAP e isso vai detonar com o IO do disco.
2) se o gargalo for CPU, e dificilmente é, o ato de reiniciar o serviço pode resolver o problema.
3) se o gargalo for IO (disco), o ato de reiniciar o serviço dá uma folga para a maquina.

SE NÃO REINICIAR O(s) SERVIÇO(s):

1) a maquina vai cair e voce nunca vai saber o que houve
2) o problema pode se repetir e voce nao vai ter nem ideia do que aconteceu se nao perder um dia monitorando apenas aquela maquina

O QUE CAUSA ISSO EM 90% DAS VEZES:
1) ataque de "flood" para um site, nesse caso o ato de reiniciar o serviço aliado à um disparo de e-mail para o administrador, levará ele para verificar o servidor e monitorar os logs de acesso ao servidor. Ontem mesmo um cliente estava sendo floodido por um usuario. Bloqueamos o usuario e tudo se resolveu.
2) falha do programador, que deixou um loop infinito em um script ou gerou um loop e nao consegui parar => se voce nao derrubar O PROCESSO, ele derruba o servidor.

Existem métodos para fazer isso, não conheço os outros, mas o que eu desenvolvi trabalha em níveis:

1) se a maquina tem mais de 8 gb de ram, até 80% de ram mata phps, em 85% de ram mata apache e reinicia em seguida, sendo quase imperceptivel para o usuario. Em 90% de ram, mata os javas. Eventualmente um java mal-configurado tambem pode gerar excesso de uso de RAM. Em 11 anos de hosting, foram raríssimos os casos em que uma maquina minha caiu por outros motivos relacionados com consumo de memoria.

2) se a maquina tem mais de 8 gb de ram, esses niveis são acrescidos de 5%.

3) se o load passar de 40, todos os processos são mortos. Eventualmente uma rotina de backup pode levar o load a 10 e isso nao significa um problema, mas falta de IO

Para resolver mais este ponto de performance, instalamos em todos os servidores, monitoramento de IO com coleta de dados a cada 15 segundos. E digo com propriedade e logs: SATA É UMA MERDA até para guardar backup.. sempre é ele que engargala, mesmo tendo 1 Gb de cache na controladora. SSD é um manjar dos Deuses...

Se voce tem o servidor na mao, e sabe o que ocorre com ele, nao vejo problema em derrubar o serviço. Outro fato: nem sempre o dono do site sabe mexer no site, às vezes quem mexe é o desenvolvedor e ele não está afim de otimizar. Ele até aceita pagar mais caro para você segurar a bomba. E aí?

[little_oak]

Juliano P
Só faltou mencionar que sata degrada MUITO facilmente, e ainda pior, processadores sem stand bridge simplesmente apresentam um delay do tamanho da face da terra no momento da troca de dados com o sata.
Realmente SSD é benção, principalmente se for SLC.

[Tiago Matos]

Massa a discussão. Além dos experts os newbe podem participar? hehehe
Bem pessoal, eu sou meio novo em adm de servidores e estou me familiarizando agora com este novo trabalho.

Eu tenho Cpanel + Centos como de costume. Alguém poderia me dá uma dica se como "percebo" que o load está alto? Sei que é o load average que exibe no WHM, mas são tantos números que até hoje não consegui identificar, até quanto está bom ou ruim.

Outra dica que iria me ajudar bastante é se o servidor sobrecarregar, quais os primeiros passos a tomar? Ver logs? como?

Abraços e boa discussão. Estou acompanhando em background!

[Juliano P]

Tiago,

Como ver LOAD ALTO: loga no ssh e digita

uptime

Vai retornar algo tipo isso:
20:08:17 up 137 days, 7:51, 2 users, load average: 2.50, 2.48, 2.26

Load average é o "load".

Alto vai de cada um... pra mim alto é quando o primeiro número passa de 3. O segundo número é a média do load average dos últimos 5 minutos e o terceiro número é a média do load average dos últimos 15 minutos.

Em termos mais técnicos, o "2.5" significa que existem 2.5 processos na fila para serem processados pelo processador. Dependendo do clock, isso é imperceptível. Dependendo da aplicação, um load de 10 também não pode ser percebido, mas se tu entrar no SSH, vai sentir a lentidão em qualquer comando, principalmente de disco.

O load é a combinação de MEMORIA + CPU + IO, entao se ele tiver alto, é algo relacionado com um dos três componentes.

MEMORIA: loga no ssh e digita

free

Vai retornar algo tipo isso

total used free shared buffers cached
Mem: 12459256 12028904 430352 0 449556 5867936
-/+ buffers/cache: 5711412 6747844
Swap: 6144852 630284 5514568

Significa que:
1) a maquina tem 12459256 (12 Gb) de RAM
2) 430352 (430 Mb) nem foram tocados
3) 5867936 (5 Gb) estao sendo usados para cache (de IO principalmente)
4) 6747844 (6 Gb) estão LIVRES para uso.

Livres? Sim, se o sistema operacional precisar, ele vai baixar o "cached" e disponibilizar para a aplicação.

E por último, essa maquina tem um espaço em disco disponível para SWAP de 6144852 (6 Gb) e está sendo usado 630284 (600 Mb) ... não é bom, mas acontece. Algumas aplicações com baixo uso de memoria acabam sendo relegadas para o Swap. Uma das maneiras de ajudar a máquina a não usar o SWAP (que deixa lento, mas é necessário, pois sem ele a máquina poderá travar na ausência de memoria disponivel), execute este comando sem qualquer risco:

echo 20 > /proc/sys/vm/swappiness

Ele vai dizer para o kernel usar swap em uma proporção de necessidade de 20% ao invés do padrão que se não me engano é 80.

CPU: loga no ssh e digita

ps auxw

OU

top

Ele vai te listar os processos e com isso, na coluna CPU, vais poder ver quem usa mais. Em maquinas multiprocessadas é comum um processo usar mais de 100% de CPU (pois ele vai usar mais de uma CPU, por que a máquina tem mais de uma CPU, lembra?)

No top, você pode verificar também o estado geral do processamento do servidor, por exemplo:

Cpu0 : 52.8%us, 4.0%sy, 0.0%ni, 40.6%id, 0.0%wa, 0.3%hi, 2.3%si, 0.0%st
Cpu1 : 19.8%us, 1.7%sy, 0.0%ni, 78.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st

Cpu0: 52% em uso por aplicações (Apache, ftp, email, etc), 4% por sistema (kernel, placa de rede), 40% idle (disponivel, excelente), 0.0% wa = IO (excelente, nenhuma aplicação aguardando o disco responder)

Cpu1: 19% em uso por aplicações (Apache, ftp, email, etc), 1% por sistema (kernel, placa de rede), 78% idle (disponivel, excelente), 0.0% wa = IO (excelente, nenhuma aplicação aguardando o disco responder)

Na maquina que peguei como exemplo, são 8 cores e a media do "used" está em 50%, o que é bom para uma maquina "fechada" (nao entra mais nada nela).

No ps, por exemplo:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
usuarioapache 21001 1.5 2.1 801608 262464 ? S 14:05 5:42 /usr/local/apacheseguro/bin/httpd -DSSL
usuarioapache 21002 1.1 1.8 784436 230284 ? S 14:05 4:21 /usr/local/apacheseguro/bin/httpd -DSSL
usuarioapache 21003 1.2 2.0 809684 256460 ? S 14:05 4:30 /usr/local/apacheseguro/bin/httpd -DSSL
usuarioapache 21004 1.3 1.9 801300 245644 ? S 14:05 5:11 /usr/local/apacheseguro/bin/httpd -DSSL
usuarioapache 21005 1.0 1.9 802820 241592 ? S 14:05 3:59 /usr/local/apacheseguro/bin/httpd -DSSL
usuarioapache 21006 1.1 1.9 804356 247000 ? S 14:05 4:11 /usr/local/apacheseguro/bin/httpd -DSSL

Significa que temos o usuario usuarioapache rodando o processo httpd (servidor web apache), com seus respectivos PIDs, respectivo uso de CPU e MEMORIA, a hora que o processo foi inicializado (pode ter sido ontem ou no ano passado tambem) e o tanto de memoria ram que o processo está usando (RSS), ou memoria residente. No caso citado, cada processo do apache está usando 240 Mb de memoria em media.

IO

No centos tem um pacote bem legal chamado sysstat, (yum install sysstat), que dá o iostat

No iostat tu pode tirar um relatorio da situação do HD, por exemplo

/usr/bin/iostat -d sda -x 15 -t

Vai informar a cada 15 segundo o status de IO do disco

Exemplo:
Device rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
Time: 20:20:09 => sda 0.00 65.89 0.13 23.97 2.14 718.83 29.92 0.20 8.47 1.03 2.49
Time: 20:20:24 => sda 0.00 18.25 0.00 17.85 0.00 288.87 16.18 0.36 20.32 0.82 1.47
Time: 20:20:39 => sda 0.00 18.48 0.00 12.21 0.00 245.50 20.11 0.15 12.16 0.71 0.87
Time: 20:20:54 => sda 0.00 15.60 0.53 18.67 4.27 274.13 14.50 1.81 94.14 2.16 4.15
Time: 20:21:09 => sda 0.00 75.12 0.20 19.61 2.13 757.84 38.36 0.06 3.12 0.76 1.51
Time: 20:21:24 => sda 0.00 27.07 0.80 24.00 46.93 408.53 18.37 1.84 74.00 2.02 5.01

Este HD está com uso medio de 3% de IO, existem alguns picos de processos aguardando a gravação (await), mas esse dado não é muito confiável segundo o desenvolvedor do software, ele dá o numero de IOPs por segundo (r/s e w/s), que em um hd SAS de 15k nao deve passar de 200 a 300 (nao sei quanto a SATA).

O dado que eu mais levo em consideração é a porcentagem de uso (o %util)... esse é sempre certo. Se a maquina está com isso em 100% é certo que o negocio nao vai andar rapido até baixar o IO. E aí tem que sair atrás da aplicação que está usando o disco.

O iostat funciona bem quando voce deixa ele rodando em "loop", ou seja, com -x "alguma coisa", do contrario ele dá informações não muito verídicas, pois nao tem como medir "o antes" para tirar o uso atual de IO