Por que o tempo de resposta está explodindo quando a frequência da solicitação cai?

22

Correção : o tempo de resposta ( %D) não é ms! 1 1

Isso não muda nada sobre a estranheza desse padrão, mas significa que é praticamente muito menos devastador.

Por que o tempo de resposta está inversamente correlacionado para solicitar a frequência?

O servidor não deve responder mais rapidamente quando está menos ocupado processando solicitações?

Alguma sugestão de como fazer o Apache "tirar vantagem" de menos carga?

Esse padrão é periódico. Isso significa que ele será exibido se as impressões caírem abaixo de cerca de 200 solicitações por minuto - o que acontece (devido à atividade natural do usuário) do início da noite até o início da manhã.

Os pedidos são POSTs muito simples, enviando um JSON com menos de 1000 caracteres - esse JSON é armazenado (anexado a um arquivo de texto) - é isso. A resposta é apenas "-".

Os dados mostrados nos gráficos foram registrados com o próprio Apache:

LogFormat "%{%Y-%m-%d+%H:%M:%S}t %k %D %I %O" performance
CustomLog "/var/log/apache2/performance.log" performance

apache-2.4 ubuntu-14.04 high-load

— Raffael
fonte

2

É possível que algo esteja causando pressão no cache e, como resultado, seja necessário buscar novamente as coisas do disco? Como é a atividade do disco?

— TLW 21/07

2

Essas solicitações chegam por minuto ou são processadas por minuto?

— precisa saber é o seguinte

Qual software você usou para registrar e plotar esses dados? Verdadeiramente curioso

— Délisson Junio 21/07

1

@wingleader: gravado com Apache2 e plotado com R

— Raffael

@immibis: ver a configuração log que acrescentei - Eu acho que é "chegada"

— Raffael

31

Esse é um comportamento comum nos datacenters. O tempo em que o tempo de resposta é lento corresponde ao que é comumente chamado de Janela de Lote. É um período em que a atividade do usuário deve ser baixa e processos em lote podem ser executados. Os backups também são feitos durante esse período. Essas atividades podem sobrecarregar os recursos do servidor e das redes, causando problemas de desempenho, como você vê.

Existem alguns recursos que podem causar problemas:

Carga alta da CPU. Isso pode fazer com que o apache aguarde um intervalo de tempo para processar a solicitação.
Alto uso de memória. Isso pode liberar buffers que permitem ao apache servir recursos sem lê-los no disco. Também pode causar paginação / troca de trabalhadores apache.
Atividade de disco alta. Isso pode fazer com que a atividade de E / S do disco seja enfileirada com atrasos correspondentes na veiculação de conteúdo.
Alta atividade de rede. Isso pode fazer com que os pacotes sejam enfileirados para transmissão, aumentem novas tentativas e degradam o serviço.

Eu uso sarpara investigar emitidos assim. atsarpode ser usado para coletar sardados em arquivos de dados diários. Eles podem ser examinados para ver como é o comportamento do sistema durante o dia, quando o desempenho é normal, e sobrescrever, quando o desempenho é variável.

Se você estiver monitorando o sistema com muninou algum outro sistema que reúna e represente graficamente a utilização de recursos, poderá encontrar alguns indicadores lá. Ainda acho sarmais preciso.

Existem ferramentas como nicee ioniceque podem ser aplicadas a processos em lote para minimizar seu impacto. Eles são eficazes apenas para problemas de CPU ou E / S. É improvável que eles resolvam problemas com a atividade de memória ou rede.

Movendo a atividade de backup para uma rede separada e reduza a contenção da rede. Alguns softwares de backup podem ser configurados para limitar a largura de banda que será usada. Isso pode resolver a contenção da rede.

Dependendo de como os processos em lote são acionados, você poderá limitar o número de processos em lote em execução em paralelo. Isso pode realmente melhorar o desempenho dos processos em lote, pois eles provavelmente estão enfrentando a mesma contenção de recursos.

— BillThor
fonte

1

Um link para sarpode ser útil. Eu encontrei esta: en.wikipedia.org/wiki/Sar_(Unix)

— Roger Lipscombe

Isto pode não ser apenas backups, prestadores de VM pode se mover mais vm de que as mesmas máquinas em tempos de parada e desligar algumas prateleiras para economizar energia (ou, na verdade, dedicá-los a tarefas de lote)

— Jens Timmerman

8

Essa relação pode ocorrer na outra direção se os remetentes da solicitação aguardarem a conclusão de uma solicitação anterior antes de enviar uma nova. Nesse caso, o tráfego diminui conforme o tempo de solicitação aumenta (por qualquer motivo), devido ao enfileiramento do lado do cliente.

Ou pode ser um artefato da sua medição - se o gráfico acima mostra solicitações concluídas , em oposição às solicitações de chegada , a taxa diminui conforme o tempo de processamento da solicitação aumenta (assumindo capacidade finita: D).

— Karol Nowak
fonte

É claro que isso está apenas arranhando a superfície de possíveis razões, mas a declaração do problema de abertura não dá muito o que olhar. Esse processo fala com mais alguma coisa? Que tipos de solicitações ele atende? A carga de trabalho muda com o tempo? E assim por diante ...

— Karol Nowak

perspectiva interessante, mas não vai bem com a periodicidade e duração dos sintomas

— Raffael

7

Embora a resposta do @ BillThor possa estar correta, parece improvável que o período de baixa carga seja totalmente ocupado pelos processos de backup (ou seja, que os períodos correspondam com precisão).

Uma explicação alternativa é simplesmente o armazenamento em cache. Se um determinado script / banco de dados / o que não tiver sido usado recentemente, os dados em cache relevantes podem ter sido descartados para liberar memória para o restante do sistema operacional. Podem ser índices em um banco de dados ou buffers de O / S em relação a um arquivo ou qualquer outra coisa semelhante. Uma consulta precisará reconstituir essas informações se já faz algum tempo desde a última consulta. Nos períodos de maior movimento, isso não ocorrerá, pois a última consulta será frequente. Isso também explicaria por que você vê baixos tempos de resposta e altos tempos de resposta durante o período ocupado.

— abligh
fonte

Especialmente se o cache de consultas e / ou o cache de acesso ao disco estiverem envolvidos. Além disso, se houver alguma estratégia de "reutilização de threads" que também ajude.

— Mckenzm

Não há nenhum tipo de leitura envolvida.

— Raffael

1

@ Raffael Eu duvido muito que você possa garantir "não há leitura de nenhum tipo envolvido". Em um nível trivial, suponha que as páginas do Apache sejam paginadas porque outra coisa queria a RAM? Suponha que o seu MPM para Apache tenha reduzido o número de threads / processos enquanto as coisas estão ociosas e há sobrecarga na criação de novas? Você está dizendo seriamente que, se você executar straceo processo Apache, não verá read()chamadas do sistema ou similares? Isso seria bem incomum.

— abligh

@abligh: bem, correto, meu "serviço" não implementa explicitamente nada de leitura do disco

— Raffael

@Raffael se você quiser testar o efeito do cache do SO (apenas), durante um período ocupado, faça a echo 3 > /proc/sys/vm/drop_cachescada 5 segundos por um minuto e veja se você obtém efeitos semelhantes no tempo de resposta.

— abligh

2

O que você está vendo lá parece, para mim, como um problema estatístico. Pode não ser, a resposta de @ BillThor pode estar certa, mas vou postar isso por completo.

Os gráficos do tempo de resposta são baseados em percentis. Um conjunto de amostras de 800-1000 solicitações é uma boa contagem de amostras para isso, um conjunto de 50 a 100 solicitações talvez não tanto.

Se você presumir que o número de solicitações lentas não é uma função linear do volume de solicitações, de modo que um aumento de ordem de magnitude nas solicitações não resulte em um aumento de ordem de magnitude nas solicitações lentas, volumes maiores de solicitações resultarão em menor tempo médio de solicitação.

— Kaithar
fonte

1

se a observação fosse composta apenas de 50 a 100 solicitações, na verdade isso poderia ser apenas aleatório, mas se você olhar para o gráfico, verá que estamos falando de experiências de 60 x 5, cada uma envolvendo cerca de 50 a 100 solicitações - isso é definitivamente o suficiente para descartar a aleatoriedade. Além disso, se você olhar atentamente, verá um percentil 50 médio estável emergindo a cerca de 2500ms.

— Raffael

Não necessariamente, não é bem assim que esse tipo de estatística se comporta em massa. Por exemplo, 1000 solicitações em 1 hora e 1000 solicitações em 1 minuto não se comportarão da mesma maneira. Provavelmente também não está acontecendo aqui. Amostras pequenas se comportam de maneira estranha, nesse caso é mais como conjuntos de amostras de 60x5. O padrão pode ser resultado de carregamento não linear.

— 27416 Kaithar

0

Existem mentiras, grandes mentiras e estatísticas.

Minha hipótese: você tem três categorias distintas de solicitações:

O fluxo variável normal que contém a maioria dos pedidos e todos eles são concluídos dentro de 200-300 μs.
Fluxo pequeno a uma taxa constante de cerca de 20 solicitações por minuto (mesmo à noite). Cada um leva cerca de 2.500 μs para ser concluído.
Fluxo minúsculo a uma taxa constante de cerca de 10 solicitações por minuto (mesmo à noite). Cada um leva bem acima de 4.000 μs.

À noite, os 50 pedidos por minuto são correspondentemente 20 + 20 + 10. E assim, o resultado do percentil de 50% agora depende fortemente do resultado do fluxo 2. E o percentil de 95% depende do fluxo 3, para que ele nunca seja exibido no gráfico.

Durante o dia, os fluxos 2 + 3 ficam bem escondidos acima do percentil 95%.

— kubanczyk
fonte

O que você quer dizer com stream? Os pedidos são absolutamente homogêneos, enquanto os clientes que solicitam são absolutamente heterogêneos.

— Raffael

0

Quanto mais eu olho para ele, mais inclinado a pensar que há um problema com a coleta de dados.

Primeiro, há algo realmente estranho acontecendo com o seu TPS. Embora o padrão geral pareça normal, ocorre uma interrupção muito acentuada por volta das 21h e depois novamente às 7h. Um gráfico normal será muito mais suave durante a transição para os horários de menor movimento.

Isso sugere que há uma alteração no perfil e você pode ter dois tipos distintos de clientes:

Um que opera apenas entre 7h (21h) e 21h (ish), em grandes volumes e
outro que provavelmente opera o tempo todo, em volumes mais baixos.

A segunda dica é por volta das 18:00. Na maioria das vezes, antes e depois, temos o perfil de alto volume - TPS alto e baixa latência. Mas por volta das 18:00, há uma queda repentina de 800-1000 RPM para menos de 400 RPM. O que poderia causar isso?

A terceira dica é a redução nos tempos de resposta do 5º percentil. Na verdade, eu prefiro observar os tempos de resposta mínimos (mas o 5º percentil é possivelmente melhor) por dois motivos: informa o tempo de serviço (ou seja, tempo de resposta menos o enfileiramento) e os tempos de resposta tendem a seguir uma distribuição Weibull, o que significa que o modo (ou o valor mais comum) está logo acima do mínimo.

Portanto, a redução no quinto percentil diz-me que há uma interrupção repentina na série, e o tempo de serviço diminuiu mesmo que a variação e o tempo médio de resposta tenham aumentado bastante.

Próximos passos

Nesta fase, eu mergulhava fundo nos logs para descobrir o que há de diferente nas amostras de baixo volume às 18:00 em comparação com as amostras de alto volume antes e depois dela.

Eu procuraria:

diferenças na localização geográfica (caso a latência esteja afetando o $ request_time)
diferenças no URL (não deve ser nenhuma)
diferenças no método HTTP (POST / GET) (não deve ser nenhum)
solicitações repetidas do mesmo IP
e outras diferenças ...

BTW, o 18:00 "evento" é evidência suficiente para mim que não tem nada a ver com congestionamento / atividade do data center. Para que isso seja verdade, o congestionamento teria que causar uma queda no TPS, o que é possível às 18:00, mas extremamente improvável que esteja causando uma queda sustentada e suavemente curvada no TPS por 10 horas entre 21:00 e 07:00.

— Nathan Webb
fonte