bROWiki - Sobrecarga no servidor

[MBrauna|R|]

Acredito que o servidor do site bROWiki esteja fora do ar por motivos de sobrecarga no Apache e no MySQL, como outrora apanhei muito para descobrir o problema, e tenho certeza que vocês fizeram caquinha nas configurações que eu havia adicionado.

 

 

Em questão de configuração, o site só caiu 1x (2013) e de imediato foi corrigido, após isto caía por culpa do Dundé realizar alterações em lote nas páginas utilizando de mais de um grupo de usuários (O que eu já havia relatado para não fazer, e inclusive gerou a recente queda do site, aonde o se perdeu a base de dados recente e o mesmo não soube procurar por um backup na pasta raiz.)

 

Em sua grande maioria resultado de uma péssima configuração nos caminhos:

/etc/httpd/conf.d/httpd.conf
/etc/my.cnf

 

Tal configuração atua para sobrecarregar o servidor da seguinte forma:

- Ao iniciar o serviço Apache e MySQL as configurações são levadas ignorando a configuração de hardware, afinal, é esperado que quem configurou saiba o que está realizando.

- Ao detectar que um usuário qualquer está tentando acessar alguma página do site, uma requisição ao Apache (Aka HTTPD) é gerado.

- O mesmo observa quanto de banda e quanto de recurso do servidor está liberado (X%) para que ele realize algum procedimento.

- A configuração inválida é levada como verdadeira.

- A requisição consome Y% do servidor (Isto para um caso apenas).

- Como o site não depende apenas do HTTPD ele convoca o PHP, que por sua vez observa quanto de carga está apto a utilizar e quanto ainda tem disponível.

- O PHP consome (X%-Y%), o que sobrou da requisição, e como ele não atua sozinho, realiza uma chamada no MySQL.

- O MySQL por sua vez consome uma porcentagem do servidor, vamos chama-lo de W%, novamente lembrando que a cada requisição ele realiza isto.

- O Apache se configurado para manter a conexão com o requisitante, obtém ((X%) + (W%)) e prossegue com esta porcentagem alocada.

 

-- -- -- -- -- -- --

Agora vamos imaginar o óbvio:

Vamos supor que exista por minuto 78 pessoas acessando o site, logo 78 requisições alocadas consumindo uma configuração incorreta, em dado ponto o servidor fica sobrecarregado, impossibilitando de gerar novas requisições para quem está tentando um acesso novo e também impossibilitando dos que estão já presentes de gerar uma nova, em dada momento o servidor se perde e tenta matar os processos já alocados para responder as novas requisições, é agora que o bicho pega ainda mais, como a comunicação entre Apache, MySQL e PHP para com a plataforma MediaWiki se dá através de requisições e após receber a informação é levada para a página, em sua grande maioria através de um JSON, o processo não morre criando zumbis.

 

A minha dica é simples:

 

Diminua a quantidade de pacotes enviados no Apache, reconfigure o MySQL para não armazenar cache das pesquisas e consumir pouca banda.

 

 

Apache.

## Para iniciar como um Damon
ServerType standalone


## Registra o cliente IP/DNS dele, o off guarda apenas o IP gerando menos tráfego na rede.
HostnameLookups off


## Para coletar nenhuma informação detalhada do acesso, diminuindo o custo das requisições.
ExtendedStatus on

## Eu criei um loglevel personalizado para o bROWiki, não sei se removeram, ele consistia apenas em IP - Hora requisição - qtde - página, se apagaram ... façam outro, se virem(:
LogLevel browiki

# Mais de uma requisição por conexão.
KeepAlive On

# Para restringir um numero de conexões, sempre deixei 0 para permitir todas.
MaxKeepAliveRequests 0

# Segundos que aguardará a próxima requisição
KeepAliveTimeout 15

# Tempo máximo para que o servidor responda uma requisição antes de enviar uma mensagem de timeout, se passou de 60 segundos... há algo errado que não está certo.
Timeout 60

# Monitor de requisições e reguladores de pool, OLHE BEM PARA ELE, POIS ELE QUEM IRÁ GERAR O MAIOR DOS PROBLEMAS
MinSpareServers 5
MaxSpareServers 10

# Quantos servidores serão iniciados para suprir a demanda de requisições
StartServers 5

# Número máximo de servidores respondendo requisições, ELE TAMBÉM PODE TIRAR UM POUCO DO SOSSEGO
MaxClients 40

# Quantidade de requisições que um processo pode gerar antes do filho ser encerrado
MaxRequestsPerChild 10

 

P.S.: Cuidado com os módulos ativos.

 

 

Quanto ao Mysql

# Acesse a pasta abaixo e pegue o arquivo de backup, se apagaram ... bom ... faça o balanceamento manual do site.
/etc/my.cnf.bkp

 

 

Lembrando que: Ele atualmente com as configurações de hardware pode muito bem suportar mais de 5 mil acessos simultâneos, tudo dependerá das configurações inseridas.

Se aumentarem as configurações de hardware dele e não ajustarem as configurações de software ... continuará horrível.

 

Esta foi mais uma dica do tio Brauna, e não se esqueça, na dúvida use o find.

P.S.: Obrigado > por deixar o site offline no dia do meu aniversário, tomei isto como uma mensagem de gratificação por tudo prestado.

[Dundé]

Você possui acesso ao email da equipe que trabalha com isso, você mesmo passou o cargo a eles.

Não há necessidade de expor os problemas da wiki aqui, basta falar com a equipe que você recomendou.

 

Ademais, porque você finge ajudar postando no fórum, mas na wiki fica sabotando, apagando minhas edições e revertendo os guias? Sinceramente, maturidade passou longe e você só está criando uma situação infantil a si mesmo.

 

 

 

Tópico fechado.

Editado Agosto 29, 2016 por Dundé