Estratégia de registro em log do Apache em um servidor web ocupado: escrever contenção?

3

Temos um servidor da Web ocupado (> 5 milhões de acessos / dia) que atende cerca de 500.000 arquivos exclusivos. Estamos rodando o Apache no FreeBSD 7.2. De acordo com o iostat -x, o gargalo parece ser a velocidade de busca das unidades (estamos executando o RAID 1 com dois discos giratórios).

O fato de o Apache estar gravando seu log de acesso para esses mesmos discos afetando a velocidade das leituras? Você costuma adicionar um fuso separado para logs? Em caso afirmativo, você adiciona um único fuso ou RAID (obviamente, você perderá os dados do registro caso o disco falhe)?

Ou deveríamos estar empurrando os logs do Apache através de uma interface de rede para um servidor de registro central? Eu suponho, provavelmente, uma interface de rede separada do que aquele que está servindo todas as solicitações HTTP?

    
por user21715 02.10.2009 / 16:04

5 respostas

4

Ter um registro de servidor da Web ocupado em um RAID 1 é problemático. Não me lembro exatamente em que ponto tínhamos que mudar nossa estratégia de arquivamento / arquivamento, mas era algo em torno de alguns milhões de acessos por dia.

Eu tive que migrar a criação de log para discos RAID 0 e, para superar a possível perda de dados, implementei a tecnologia Scribe recém-aberta do Facebook para mover os logs para um servidor de log centralizado. Agora estamos em várias centenas de milhões de acessos por dia e estamos movendo terabytes de logs de nossos front ends, através de escriba, para um servidor central de registro que agora torna a análise desses registros, gráficos de tendências de dados e monitoramento muito mais fácil. Para seus propósitos, um único servidor de escriba trataria esse tráfego e moveria esses dados facilmente.

    
por 02.10.2009 / 16:18
1

Confira: mod_log_spread2 porto de mod_log_spread

mod_log_spread é um patch para o mod_log_config do Apache, que fornece uma interface para propagação para logs de acesso multicast. Ele utiliza o kit de ferramentas de comunicação em grupo, Spread,

E envie os logs para um coletor de logs.

    
por 02.10.2009 / 16:20
0

Eu diria que você respondeu sua própria pergunta. Ambas as suas ideias devem melhorar o desempenho do servidor da web. Se você adicionar unidades adicionais para os logs, elas devem ser o RAID 1.

    
por 02.10.2009 / 16:14
0

A criação de log para esse número de ocorrências definitivamente terá um efeito, mas quanto efeito depende do tamanho e da quantidade das solicitações reais - se os arquivos que estão sendo atendidos forem grandes, o registro em log fará pouca diferença geral e será apenas o ato de precisar ler os arquivos para atendê-los que está causando contenção de E / S. Se as solicitações de conteúdo tendem a seguir o padrão usual (muitas pessoas solicitando os arquivos mais recentes com um número relativamente pequeno de solicitações de conteúdo mais antigo), adicionar mais RAM pode ajudar, permitindo que o SO mantenha mais conteúdo no cache. Se as solicitações não seguirem um padrão útil como esse (ou seja, as solicitações de conteúdo em qualquer período de tempo não têm chance de se adaptar a uma quantidade real de RAM), isso não ajudará, é claro.

Se a atividade de registro for significativa em seu afunilamento de E / S, a movimentação dos logs para outro dispositivo certamente ajudará. Esse dispositivo pode ser outro drive / array na mesma máquina ou na rede. A menos que você esteja saturando a NIC dos servidores em qualquer ponto da atividade normal (o que é improvável - sua largura de banda externa será o gargalo), isso não precisará de uma NIC extra, a menos que a atividade de registro fique longe da interface do serviço público da Web. está ativado torna mais fácil proteger (ou de outra forma se encaixa melhor em sua organização de rede). Um link de rede não saturado não verá problemas de latência ou devido à atividade de registro do Apache, embora haja momentos em que o link seja muito usado por longos períodos. Os processos do Apache podem acabar bloqueando o tempo extra (significando que mais RAM está sendo usada horários de pico) enquanto espera que as gravações de log sejam concluídas.

Se a leitura do conteúdo for tanto (ou mais) de um problema quanto a gravação de logs, você poderá considerar usar o RAID0 para o conteúdo. Você pode precisar reforçar seus arranjos de backup para copiar com o risco extra de uma morte única unidade tirando a matriz inteira. Você poderia atenuar isso com RAID10, mas isso significaria usar quatro unidades não 2. RAID5 pode ser uma opção também para leituras ele será executado de forma semelhante ao RAID0 e só precisaria de um disco extra, mas isso não é recomendado se o conteúdo mudar frequentemente porque RAID5s gravam problemas de desempenho [cada bloco escreve, pelo menos, uma leitura extra (o (s) bloco (s) vizinho (s) e uma gravação extra (para o bloco de paridade)] irá chutá-lo. Também é melhor não ter seus arquivos de log indo para RAID5. mesma razão.

Em resumo: mover os registros para outras unidades (na mesma máquina ou pela rede) pode ajudar, assim como mover o conteúdo principal para RAID0, RAID10 ou RAID5 (aprimore seus arranjos de backup se usar R0, tenha cuidado com escreva problemas de desempenho com R5). Mais RAM também pode ajudar, reduzindo a necessidade das operações reais de E / S, se a maioria das solicitações em um determinado período de tempo for de um subconjunto de dados que seja de um número que pode caber em RAM com um bloco para tamanho de reposição.

    
por 02.10.2009 / 17:12
0

Adicionar discos separados para realizar seu registro seria um passo bastante lógico e obrigado a ajudar, pelo menos até certo ponto, com seu sistema, mas eu acho que agora é a hora de começar a considerar o futuro.

Veja como seu tráfego aumentou no site, que tipo de ritmo de crescimento você manteve e considere onde você estará 1 ano mais tarde ou até mesmo 2. Se o seu site continuar a crescer em popularidade então você precisará começar a considerar vários servidores da Web, redundância, alta disponibilidade e assim por diante. Por essa razão, sugiro que você considere o uso de rsyslog (que está em portas como rsyslog3) ou similar para lidar com o log remoto de arquivos em um servidor de backend. Então, sempre que você precisar adicionar um servidor da Web adicional, é uma tarefa simples copiar as configurações do rsyslog do servidor principal e ir embora. Ele também fornece logs em uma caixa esperançosa que não é muito contida, permitindo que você realize análises muito mais detalhadas.

    
por 02.10.2009 / 18:18