Pesquisar na Comunidade
Mostrando resultados para as tags ''por que eu quis''.
Encontrado 2 registros
-
Olá Dundé. Olha eu aqui de novo, novamente, mais uma vez, agora é para avisar que o site está fora do ar, ao menos desde hoje (Domingo 20h32min). Agradeço resolução rápida. PS:. A página de testes, aquela criada para que todos possam testar e aprender mais da plataforma mediawiki e contribuirem com o projeto, está travada para edições. Desbloqueie por favor, afinal, o projeto é tipo como nível horizontal(lembra?) e foge da idéia de ter uma página para que todos possam testar algo, uma vez que ela é bloqueada a todos exceto você. @EDIT: Ao meu ver você ignorou mesmo as dicas que dei sobre as configurações do Apache e do MySQL. Eu presumo que vocês deveriam observar estes dois processos.
-
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.
