Mauvaise performance Django / uwsgi

EDIT 1 vu le commentaire que vous avez 1 noyau virtuel, en ajoutant des commentaires sur tous les points relavant

EDIT 2 plus d'informations de Maverick, donc j'élimine les idées exclues et développe les problèmes confirmés.

EDIT 3 rempli plus de détails sur la file d'attente de demandes uwsgi et les options de mise à l'échelle. Amélioration de la grammaire.

Modifier 4 mises à jour de Maverick et améliorations mineures

Les commentaires sont trop petits, alors en voici quelques-uns pensées:

1. la moyenne de charge est essentiellement le nombre de processus en cours d'exécution ou en attente de L'attention du processeur. Pour un système parfaitement chargé avec 1 noyau CPU, la moyenne de charge devrait être 1.0; Pour un système 4 core, il devrait être 4.0. Au moment où vous exécutez le test web, les fusées de threading et vous avez un lot {[28] } de processus en attente de CPU. À moins que la moyenne de charge dépasse le nombre de cœurs de processeur d'une marge significative, ce n'est pas un problème
2. le premier "temps par requête" la valeur de 4s est corrélée à la longueur de la file d'attente de requêtes - 1000 requêtes déversées sur Django presque instantanément et ont pris en moyenne 4s en service, dont environ 3,4 s étaient en attente dans une file d'attente. Cela est dû à l'inadéquation très importante entre le nombre de demandes (100) et le nombre de processeurs (16), ce qui fait que 84 des demandes attendent un processeur à un moment donné.

3. S'exécutant à une concurrence de 100, les tests prennent 41 secondes à 24 requêtes / sec. Vous avez 16 processus (threads), donc chaque requête est traitée environ 700ms. étant donné votre type de transaction, c'est un long Temps par requête. Cela peut être parce que:

   1. Le coût CPU de chaque requête est élevé dans Django (ce qui est hautement improbable étant donné la faible valeur CPU de la barre d'outils de débogage)
   2. le système d'exploitation change beaucoup de tâche (surtout si la moyenne de charge est supérieure à 4-8), et la latence est purement due à un trop grand nombre de processus.
   3. Il N'y en a pas assez de connexions DB desservant les 16 processus pour que les processus attendent d'en avoir un Disponible. Avez-vous au moins une connexion par processus?

   4. Il y a une latence considérable autour de la base de données, soit :

      1. des dizaines de petites demandes prenant chacune, disons, 10ms, dont la plupart sont des frais généraux de mise en réseau. Si oui, pouvez-vous introduire la mise en cache ou réduire les appels SQL à un nombre plus petit. Ou
      2. un ou deux les requêtes prennent 100 de ms. pour vérifier cela, exécutez le profilage sur la base de données. Si c'est le cas, vous devez optimiser cette demande.

4. La répartition entre le coût du processeur du système et de l'utilisateur est inhabituellement élevée dans le système, bien que le CPU total soit faible. Cela implique que la plupart du travail dans Django est lié au noyau, comme la mise en réseau ou le disque. Dans ce scénario, il peut s'agir de coûts réseau (par exemple, recevoir et envoyer des requêtes HTTP et recevoir et envoyer des requêtes à la base de données). Parfois, cela sera élevé à cause de pagination . S'il n'y a pas de pagination en cours, alors vous n'avez probablement pas à vous soucier de cela du tout.

5. Vous avez défini les processus à 16, mais vous avez une moyenne de charge élevée (à quelle hauteur vous n'indiquez pas) . Idéalement, vous devriez toujours avoir au moins un processus en attente de CPU (pour que les CPU ne tournent pas les bras croisés). Les processus ici ne semblent pas liés au processeur, mais ont une latence significative, vous avez donc besoin de plus de processus que de cœurs. Combien plus? Essayez d'exécuter l'uwsgi avec différents nombres de processeurs (1, 2, 4, 8, 12, 16, 24, etc) jusqu'à ce que vous ayez le meilleur débit. Si vous modifiez la latence du processus Moyen, vous devrez l'ajuster à nouveau.
6. le niveau de concurrence 500 est certainement un problème, mais est-ce le client ou le serveur? Le rapport indique que 50 (sur 100) avaient la longueur de contenu incorrecte, ce qui implique un problème de serveur. Le non-2xx semble également pointer là. Est-il possible de capturer le non-2xx les réponses pour le débogage-les traces de pile ou le message d'erreur spécifique seraient incroyablement utiles (EDIT) et sont causées par la file d'attente de requêtes uwsgi s'exécutant avec sa valeur par défaut de 100.

Donc, en résumé:

1. Django semble bien
2. incompatibilité entre la concurrence du test de charge (100 ou 500) et les processus (16): vous poussez beaucoup trop de demandes simultanées dans le système pour le nombre de processus à gérer. Une fois que vous êtes au-dessus de la nombre de processus, tout ce qui se passera est que vous allongerez la file D'attente de requêtes HTTP dans le serveur web

3. Il y a une grande latence, donc soit

   1. Discordance entre les processus (16) et les cœurs de processeur (1): si la moyenne de charge est >3, Il y a probablement trop de processus. Essayez à nouveau avec un plus petit nombre de processus

      1. moyenne de Charge > 2 - > Essayez 8 processus
      2. Charge moyenne > 4 -> essayez 4 processus
      3. charge moyenne > 8 -> essayez 2 processus

   2. si la moyenne de charge

4. sans capturer la réponse échouée, il n'y a pas grand-chose que je puisse dire sur les échecs à 500 concurrence

Le Développement des idées

Votre charge moyenne >10 sur un seul noyau la machine estvraiment méchante et (comme vous l'observez) conduit à beaucoup de changement de tâche et à un comportement lent général. Personnellement, je ne me souviens pas avoir vu une machine avec une moyenne de charge de 19 (que vous avez pour 16 processus) - félicitations pour l'avoir si élevée ;)

Les performances de la base de données sont excellentes, donc je dirais que tout est clair en ce moment.

Paging : pour répondre à votre question sur la façon de voir la pagination - vous pouvez détecter la pagination du système D'exploitation de plusieurs façons. Par exemple, en haut, l'en-tête a la page-tenants et aboutissants (voir la dernière ligne):

Processes: 170 total, 3 running, 4 stuck, 163 sleeping, 927 threads                                                                                                        15:06:31
Load Avg: 0.90, 1.19, 1.94  CPU usage: 1.37% user, 2.97% sys, 95.65% idle  SharedLibs: 144M resident, 0B data, 24M linkedit.
MemRegions: 31726 total, 2541M resident, 120M private, 817M shared. PhysMem: 1420M wired, 3548M active, 1703M inactive, 6671M used, 1514M free.
VM: 392G vsize, 1286M framework vsize, 1534241(0) pageins, 0(0) pageouts. Networks: packets: 789684/288M in, 912863/482M out. Disks: 739807/15G read, 996745/24G written.

Nombre de processus: Dans votre configuration actuelle, le nombre de processus est chemin trop élevé. redimensionnez le nombre de processus à un 2 . Nous pourrions apporter cette valeur plus tard, en fonction du déplacement de la charge supplémentaire de ce serveur.

Emplacement du Benchmark Apache : la moyenne de charge de 1,85 pour un processus me suggère que vous utilisez le générateur de charge sur la même machine que uwsgi - est-ce exact?

Si c'est le cas, vous devez vraiment l'exécuter à partir d'une autre machine, sinon les tests ne sont pas représentatifs de la charge réelle - vous prenez de la mémoire et du processeur des processus web pour l'utiliser dans le générateur de charge. En outre, les threads 100 ou 500 du générateur de charge stresseront généralement votre serveur d'une manière qui ne se produit pas dans la vie réelle. En effet, cela pourrait être la raison pour laquelle tout le test échoue.

Emplacement de la base de données : la moyenne de charge pour un processus également suggérez que vous exécutez la base de données sur la même machine que les processus web - est-ce correct?

Si j'ai raison sur la base de données, la première et la meilleure façon de commencer à mettre à l'échelle est de déplacer la base de données vers une autre machine. Nous faisons cela pour deux raisons:

1. Un serveur de base de données a besoin d'un profil matériel différent d'un nœud de traitement:

   1. Disque: DB a besoin de beaucoup de rapide, redondant, disque sauvegardé, et un nœud de traitement juste besoin d'un disque de base
   2. CPU: UN le nœud de traitement a besoin du processeur le plus rapide que vous pouvez vous permettre alors qu'une machine DB peut souvent se passer (souvent ses performances sont bloquées sur le disque et la RAM)
   3. RAM: une machine DB a généralement besoin d'autant de RAM que possible (et la DB la plus rapide a toutes les ses données en RAM), alors que de nombreux nœuds de traitement ont besoin de beaucoup moins (le vôtre a besoin d'environ 20 Mo par processus - très petit
   4. Scaling: Atomic DBS scale le mieux en ayant des machines monstres avec de nombreux processeurs alors que le niveau web (n'ayant pas état) peut évoluer en branchant de nombreux petits boxen identiques.

2. Affinité du processeur: il est préférable que le processeur ait une moyenne de charge de 1.0 et que les processus aient une affinité pour un seul cœur. Cela maximise l'utilisation du cache du processeur et minimise les frais généraux de commutation des tâches. En séparant les nœuds de base de données et de traitement, vous appliquez cette affinité dans HW.

500 concurrence avec exceptions la file d'attente de requête dans le diagramme ci - dessus est au plus de 100-Si uwsgi reçoit une demande lorsque la file d'attente est pleine, la demande est rejetée avec un 5xx erreur. Je pense que cela se passait dans votre test de charge de concurrence 500-fondamentalement, la file d'attente s'est remplie avec les 100 premiers threads, puis les 400 autres threads ont émis les 900 requêtes restantes et ont reçu des erreurs 5xx immédiates.

Pour gérer 500 requêtes par seconde, vous devez vous assurer de deux choses:

1. La Taille de la file D'attente de requête est configurée pour gérer la rafale: utilisez l'argument --listen pour uwsgi
2. le système peut gérer un débit supérieur à 500 requêtes par seconde Si 500 est une condition normale, ou un peu inférieur si 500 est un pic. Voir les notes de mise à l'échelle ci-dessous.

J'imagine que uwsgi a la file d'attente définie sur un nombre plus petit pour mieux gérer les attaques DDoS; si elle est placée sous une charge énorme, la plupart des demandes échouent immédiatement avec presque aucun traitement permettant à la boîte dans son ensemble d'être toujours sensible aux administrateurs.

Conseils Généraux pour la mise à l'échelle d'un système

Votre considération la plus importante est probablement de maximiser le débit . Un autre besoin possible de minimiser le temps de réponse, mais je ne vais pas en discuter ici. En maximisant le débit, vous essayez de maximiser le système , pas les composants individuels; certaines diminutions locales peuvent améliorer le débit global du système (par exemple, apporter une modification qui ajoute de la latence dans le niveau web afin d'améliorer les performances de la base de données est un net gagner).

Sur les spécificités:

1. déplacez la base de données sur une machine séparée . Après cela, profilez la base de données pendant votre test de charge en exécutant top et votre outil de surveillance MySQL préféré. Vous devez être en mesure de profil . Déplacer la base de données vers une machine séparée introduira une latence supplémentaire (plusieurs ms) par requête, alors attendez-vous à augmenter légèrement le nombre de processus au niveau web pour conserver le même débit.
2. assurez - vous que la file d'attente des requêtes uswgi est grande assez pour gérer une rafale de trafic en utilisant l'argument --listen. Cela devrait être plusieurs fois le nombre maximal de demandes en état d'équilibre par seconde que votre système peut gérer.

3. Sur le niveau web / app: Équilibrez le nombre de processus avec le nombre de cœurs de processeur et la latence inhérente au processus. Trop de processus ralentit les performances, trop peu signifie que vous n'utiliserez jamais pleinement les ressources système. Il n'y a pas de point d'équilibrage fixe, car chaque application et modèle d'utilisation est différent, donc benchmark et ajuster. Comme guide, utilisez la latence des processus, si chaque tâche a:

   • 0% de latence, alors vous avez besoin de 1 processus par cœur
   • 50% de latence (c'est-à-dire que le temps CPU est la moitié du temps réel), alors vous avez besoin de 2 processus par cœur
   • 67% de latence, alors vous avez besoin de 3 processus par cœur

4. Vérifiez top pendant le test pour vous assurer que vous êtes au-dessus de 90% d'utilisation du processeur (pour chaque cœur) et Vous avez une moyenne de charge un peu au-dessus de 1.0. Si la moyenne de charge est plus élevée, réduisez les processus. Si tout va bien, à un moment donné, vous ne serez pas en mesure d'atteindre cet objectif, et DB pourrait maintenant être le goulot d'étranglement

5. à un moment donné, vous aurez besoin de plus de puissance dans le niveau web. Vous pouvez soit choisir d'ajouter plus de CPU à la machine (relativement facile) et ainsi ajouter plus de processus, et/ou Vous pouvez ajouter plus de nœuds de traitement (évolutivité horizontale). Ce dernier peut être réalisé dans uwsgi en utilisant la méthode discutée ici par Łukasz Mierzwa