Pourquoi le temps de réponse explose-t-il lorsque la fréquence des demandes diminue?

22

Correction : le temps de réponse ( %D) est μs pas ms! 1

Cela ne change rien à l'étrangeté de ce modèle, mais cela signifie qu'il est pratiquement moins dévastateur.

Pourquoi le temps de réponse est-il inversement corrélé à la fréquence de demande?

Le serveur ne devrait-il pas répondre plus rapidement lorsqu'il est moins occupé à traiter les demandes?

Une suggestion sur la façon de faire profiter Apache de moins de charge?

Ce modèle est périodique. Cela signifie qu'il apparaîtra si les impressions tombent en dessous d'environ 200 demandes par minute - ce qui se produit (en raison de l'activité naturelle des utilisateurs) de la fin de la nuit au petit matin.

Les requêtes sont des POST très simples envoyant un JSON de moins de 1000 caractères - ce JSON est stocké (ajouté à un fichier texte) - c'est tout. La réponse est simplement "-".

Les données affichées dans les graphiques ont été enregistrées avec Apache lui-même:

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
source

2

Est-il possible que quelque chose cause une pression sur le cache, et par conséquent, il doit récupérer des choses à partir du disque? À quoi ressemble l'activité du disque?

— TLW

2

Ces demandes arrivent-elles par minute ou sont-elles traitées par minute?

— user253751

Quel logiciel avez-vous utilisé pour enregistrer et tracer ces données? Véritablement curieux

— Délisson Junio

1

@wingleader: enregistré avec Apache2 et tracé avec R

— Raffael

@immibis: voir la configuration du journal que j'ai ajoutée - je pense que c'est "arrivée"

— Raffael

31

Il s'agit d'un comportement courant dans les centres de données. Le temps de réponse lent correspond à ce que l'on appelle communément la fenêtre de lot. Il s'agit d'une période pendant laquelle l'activité de l'utilisateur devrait être faible et des processus par lots peuvent être exécutés. Des sauvegardes sont également effectuées pendant cette période. Ces activités peuvent mettre à rude épreuve les ressources du serveur et des réseaux, entraînant des problèmes de performances comme vous le voyez.

Il existe quelques ressources qui peuvent provoquer des problèmes:

Charge CPU élevée. Cela peut amener apache à attendre une tranche de temps pour traiter la demande.
Utilisation élevée de la mémoire. Cela peut vider les tampons qui permettent à apache de servir les ressources sans les lire depuis le disque. Il peut également provoquer la pagination / l'échange de travailleurs apache.
Activité disque élevée. Cela peut entraîner la mise en file d'attente des activités d'E / S disque avec des retards correspondants dans la diffusion du contenu.
Activité réseau élevée. Cela peut entraîner la mise en file d'attente des paquets pour la transmission, augmenter les tentatives et dégrader le service.

J'utilise sarpour enquêter publié comme ça. atsarpeut être utilisé pour recueillir des sardonnées dans des fichiers de données quotidiens. Ceux-ci peuvent être examinés pour voir à quoi ressemble le comportement du système pendant la journée lorsque les performances sont normales et pendant la nuit lorsque les performances sont variables.

Si vous surveillez le système avec muninou un autre système qui collecte et représente graphiquement l'utilisation des ressources, vous pouvez y trouver des indicateurs. Je trouve toujours sarplus précis.

Il existe des outils comme niceet ionicequi peuvent être appliqués aux processus par lots pour minimiser leur impact. Ils ne sont efficaces que pour les problèmes de CPU ou d'E / S. Il est peu probable qu'ils résolvent les problèmes liés à l'activité de la mémoire ou du réseau.

Déplacer l'activité de sauvegarde vers un réseau distinct et réduire les conflits de réseau. Certains logiciels de sauvegarde peuvent être configurés pour limiter la bande passante qui sera utilisée. Cela pourrait résoudre les conflits de réseau.

Selon la façon dont les processus par lots sont déclenchés, vous pourrez peut-être limiter le nombre de processus par lots exécutés en parallèle. Cela peut en fait améliorer les performances des processus par lots car ils connaissent probablement le même conflit de ressources.

— BillThor
source

1

Un lien vers sarpourrait être utile. J'ai trouvé celui-ci: en.wikipedia.org/wiki/Sar_(Unix)

— Roger Lipscombe

cela pourrait non seulement être des sauvegardes, les fournisseurs de VM peuvent déplacer plus de VM vers les mêmes machines en temps d'arrêt et éteindre quelques racks pour économiser de l'énergie (ou même les consacrer à des tâches par lots)

— Jens Timmerman

8

Cette relation peut se produire dans l'autre sens si les expéditeurs de demande attendent la fin d'une demande précédente avant d'en soumettre une nouvelle. Dans ce cas, le trafic diminue à mesure que le temps de demande augmente (pour une raison quelconque), en raison de la mise en file d'attente côté client.

Ou cela peut être un artefact de votre mesure - si le graphique ci-dessus montre les demandes terminées , par opposition aux demandes arrivantes , le taux baissera à mesure que le temps de traitement des demandes augmente (en supposant une capacité finie: D).

— Karol Nowak
source

Bien sûr, cela ne fait qu'effleurer la surface des raisons possibles, mais l'énoncé du problème d'ouverture ne donne pas grand-chose à regarder. Ce processus parle-t-il d'autre chose? Quels types de demandes sert-il? La charge de travail évolue-t-elle au fil du temps? Et ainsi de suite ....

— Karol Nowak

perspective intéressante mais ne va pas bien avec la périodicité et la durée des symptômes

— Raffael

7

Bien que la réponse de @ BillThor puisse être correcte, il semble peu probable que la période de faible charge soit entièrement occupée par les processus de sauvegarde (c'est-à-dire que les périodes correspondent précisément).

Une autre explication est simplement la mise en cache. Si un script / une base de données / quelque chose n'a pas été utilisé récemment, les données en cache pertinentes peuvent avoir été supprimées afin de libérer de la mémoire pour le reste du système d'exploitation. Cela peut être des index sur une base de données, ou des tampons O / S par rapport à un fichier, ou toute autre chose similaire. Une requête va alors devoir reconstituer ces informations si cela fait un certain temps depuis la dernière requête. Dans les périodes chargées, cela ne se produira pas car la dernière requête aura été fréquente. Cela expliquerait également pourquoi vous voyez des temps de réponse faibles et des temps de réponse élevés pendant la période occupée.

— abligh
source

Surtout si la mise en cache des requêtes et / ou la mise en cache d'accès au disque sont impliquées. En aparté s'il y a une stratégie de "réutilisation des threads" qui aide aussi.

— mckenzm

Aucune lecture d'aucune sorte n'est impliquée.

— Raffael

1

@Raffael Je doute fort que vous puissiez garantir "qu'il n'y a aucune lecture d'aucune sorte". À un niveau trivial, supposons que les pages d'Apache soient paginées parce que quelque chose d'autre voulait la RAM? Supposons que votre MPM pour Apache ait réduit le nombre de threads / processus pendant que les choses sont inactives et qu'il y a des frais généraux pour en créer de nouveaux? Êtes-vous sérieusement en train de dire que si vous exécutez stracele processus Apache, vous ne voyez aucun read()appel système ou similaire? Ce serait assez inhabituel.

— abligh

@abligh: eh bien, correct, mon "service" n'implémente pas explicitement quoi que ce soit de lecture à partir du disque

— Raffael

@Raffael si vous souhaitez tester l'effet de la mise en cache du système d'exploitation (uniquement), puis pendant une période occupée, faites echo 3 > /proc/sys/vm/drop_cachestoutes les 5 secondes pendant une minute et voyez si vous obtenez des effets similaires sur le temps de réponse.

— abligh

2

Ce que vous voyez là-bas me semble être un problème statistique. Ce n'est peut-être pas le cas, la réponse de @ BillThor pourrait être juste, mais je posterai ceci pour être complet.

Les graphiques des temps de réponse sont basés sur le centile. Un pool d'échantillons de 800 à 1000 requêtes est un bon nombre d'échantillons pour cela, un pool de 50 à 100 requêtes n'est peut-être pas tellement.

Si vous supposez que le nombre de demandes lentes n'est pas une fonction linéaire du volume de demandes, de sorte qu'une augmentation de l'ordre de grandeur des demandes n'entraîne pas une augmentation de l'ordre de grandeur des demandes lentes, alors des volumes de demandes plus élevés se traduiront par temps de demande moyen inférieur.

— Kaithar
source

1

si l'observation ne comprenait que 50 à 100 demandes, alors cela pourrait être juste un hasard, mais si vous regardez le graphique, vous verrez que nous parlons de 60 x 5 expériences impliquant chacune environ 50 à 100 demandes - c'est certainement suffisant pour exclure le hasard. De plus, si vous regardez attentivement, vous verrez un 50e centile moyen stable émerger à environ 2500 ms.

— Raffael

Pas nécessairement, ce n'est pas tout à fait ainsi que ce genre de statistiques se comporte en vrac. Par exemple, 1 000 demandes sur 1 heure et 1 000 demandes sur 1 minute ne se comporteront pas de la même manière. Aussi probablement pas ici. Les petites tailles d'échantillons se comportent étrangement, dans ce cas, il s'agit plutôt de jeux d'échantillons 60x5. Le motif pourrait être le résultat d'un chargement non linéaire.

— Kaithar

0

Il y a des mensonges, de gros mensonges et des statistiques.

Mon hypothèse: vous avez trois catégories distinctes de demandes:

Le flux variable normal qui contient la majorité des demandes et celles-ci sont toutes terminées en 200-300 μs.
Petit flux à un débit constant d'environ 20 requêtes par minute (même la nuit). Chaque opération prend environ 2 500 μs.
Petit flux à un taux constant d'environ 10 requêtes par minute (même la nuit). Chacun prend bien au-dessus de 4.000 μs.

La nuit, les 50 demandes par minute sont respectivement 20 + 20 + 10. Et donc, le résultat du 50% centile dépend désormais fortement du résultat du flux 2. Et 95% du centile dépend du flux 3, il ne peut même jamais s'afficher sur le graphique.

Pendant la journée, les flux 2 + 3 sont bien cachés au-dessus du 95% percentile.

— kubanczyk
source

Que voulez-vous dire par stream? Les demandes sont absolument homogènes tandis que les clients qui les demandent sont absolument hétérogènes.

— Raffael

0

Plus j'y regarde, plus j'ai tendance à penser qu'il y a un problème avec la collecte de données.

Tout d'abord, il se passe quelque chose de vraiment bizarre avec votre TPS. Alors que le schéma global semble normal, il y a une coupure très nette se produisant vers 21 h, puis de nouveau vers 7 h. Un graphique normal sera beaucoup plus fluide pendant la transition vers les heures creuses.

Cela suggère qu'il y a un changement dans le profil, et vous avez peut-être 2 types de clients distincts:

Celui qui fonctionne uniquement entre 7 h (ish) et 21 h (ish), à des volumes élevés, et
un autre qui fonctionne probablement 24 heures sur 24, à des volumes inférieurs.

Le deuxième indice est vers 18h00. La plupart du temps avant et après, nous avons le haut profil de volume - élevé TPS et une faible latence. Mais vers 18h00, il y a une chute soudaine de 800-1000 tr / min à moins de 400 tr / min. Qu'est-ce qui pourrait éventuellement causer ça?

Le troisième indice est la réduction des temps de réponse du 5e centile. En fait, je préfère regarder les temps de réponse minimum (mais le 5e centile est peut-être meilleur) pour deux raisons: il me dit le temps de service (c'est-à-dire le temps de réponse moins la mise en file d'attente), et les temps de réponse ont tendance à suivre une distribution de Weibull, ce qui signifie que le mode (ou la valeur la plus courante) est juste au-dessus du minimum.

Donc, la descente dans le 5e centile me dit qu'il y a une interruption soudaine de la série, et le temps de service a en fait chuté même si la variance et les temps de réponse moyens ont considérablement augmenté.

Prochaines étapes

À ce stade, je plongerais profondément dans les journaux pour découvrir ce qui est différent à propos des échantillons à faible volume de 18h00 par rapport aux échantillons à volume élevé avant et après.

Je chercherais:

différences de localisation géographique (dans le cas où la latence affecte le $ request_time)
différences d'URL (ne devrait pas en être)
différences dans la méthode HTTP (POST / GET) (ne devrait pas en être)
demandes répétées de la même IP
et toutes autres différences ...

BTW, "l'événement" de 18h00 est une preuve suffisante pour moi que cela n'a rien à voir avec la congestion / l'activité du centre de données. Pour que cela soit vrai, la congestion devrait entraîner une baisse du TPS, ce qui est possible à 18h00 mais extrêmement peu susceptible de provoquer une baisse soutenue et incurvée du TPS pendant 10 heures entre 21h00 et 7h00.

— Nathan Webb
source