Como amenizar o impacto do cpbackup no cpanel quando usa o Rsync

Standard

Das coisas que acho interessante no cpanel é a flexibilidade com que as coisas operam.
O Cpanel em si não é um problema, porém, vamos analisar um caso aonde o horário comercial começou e o nosso backup ainda está moendo, moendo e moendo… no momento em que o rsync começa a trabalhar uma coisa que arrebenta bastante é justamente quando ele inicia e chama as fg -rlptD, isso faz com que o I/O fique piradoooo.

Uma forma de cortar um pouco o peso desse i/o é indo no arquivo cpbackup (/usr/local/cpanel/scripts/cpbackup) e acrescentar o recurso de banda de i/o ao rsync, isso vai amenizar uns 50% do peso do backup.

Uma forma simples que aplico nos servidores que gerencio e roda de forma bem bacana é a seguinte:

Localizando a linha my $rsyncopts = ‘-rlptD’; acrescente e deixe assim:

my $rsyncopts = ‘-rlptD –bwlimit=7000’;

 

Isso vai fazer com que o rsync trafegue no disco um peso de 7mbps, apesar de um pouco lento, caso alguns sites necessitem de leitura e escrita de disco terão uma boa folga para trabalharem sob leveza.

O valor da flag bwlimit é medida em KBPS, se você quiser colocar mais ou menos é fácil, mas eu deixo esse valor baseado na resposta do hdparm (hdparm -tT /dev/sda ou sdX aonde X é a letra do seu disco), o hdparm além de confirmar se o motor do disco está bom ainda te dá uma resposta de potência de leitura e escrita.

ps: Algo que faço por minha conta e risco é chattr +ai /usr/local/cpanel/scripts/cpbackup para bloquear o arquivo, mas não é bom em detrimento de mudanças constantes do cpanel (isso é coisa minha, mas se não fizer, na update seguinte ele sobrescreverá este arquivo :'(  ).

Abração pessoALL ;).

Fazendo análise de disco e análise básica de um servidor

Standard

dmesg | grep -i err

Irá verificar erros recentes, problemas de RAM, aplicativos gerando qualquer log de erro significativo pro sistema operacional

tail -f -n XXXXX /var/log/messages

Similar ao anterior. XXX é o numero de linhas para trás. Sempre que o servidor travar, procure as ultimas entradas neste arquivo antes do travamento.

hdparm -Tt /dev/sda (sda, sdb, md0… seja qual for seu disco)

Te dá um relatório de leitura e escrita pro seu disco.

Os valores mínimos aceitáveis são:
Timing cached reads superior a 700
Timing buffered disk reads superior a 25

Se estiver inferior, é grande chance de problema no disco.

Faz um “top” e acompanha o parametro “wa” ou “iowait”.

Este parametro é o quanto seu sistema operacional espera por leitura/escrita do disco. Se durante 5 minutos esse parametro se mantiver muito alto (a cima de uns 60-70%), pode indicar sobrecarga do servidor e/ou problema no disco.

Servidor travou. Será que é Firewall?

Não é dificil acontecer. As vezes o firewall pode estar em um nível de segurança muito alto (acontece muito com o CSF), e o servidor barra todo o tráfego sainte. Tente desativar o Firewall por alguns dias. Não é nada bom ficar sem firewall, mas ir por eliminação nunca faz mal. O APF é uma boa alternativa de firewall pra Linux.

Se usar o CSF, nunca esqueça de sempre fazer update nele.

Alugue um KVM remoto

Outra dica nossa, seria pedir a instalação de um KVM remoto. Desta forma você consegue verificar de forma segura a temperatura do processador, gabinete e outros parametros. Quando o servidor travar, você terá acesso total a máquina e poderá investigar uma possível mensagem de erro no sistema (se houver).

É basicamente isso.. Existem muitas variáveis. Principalmente quando muitos clientes rodam aplicações que desconhecemos.

fonte: http://littleoak.wordpress.com/2009/08/14/fazendo-analise-de-disco-e-analise-basica-de-um-servidor/