Bonjour,

Vous avez du remarquer, depuis quelques jours (même peut-être 10 ou 15, en fait), que les performances sur Lexpage sont loin d'être au beau fixe. Je suspectais quelque chose du coté de la database vu que ces lenteurs avaient tendance à se provoquer essentiellement sur les pages "lourdes" (accueil, listing des billets, listing des discussions, ...) mais cela semble concerner aussi bien la partie Python (Lexpage) que PHP (Piwik analytics).

Je copie-colle mon message à Tchou (qui m'a remonté un complément d'information aujourd'hui) :

J'ai rebooté le serveur, cela n'a rien changé. J'ai des workers uwsgi qui spawn comme il faut, même si à chaque requête, cela bouffe un peu de CPU (environ 30 à 40%), rien de dramatique. Je vois dans les logs de Supervisor que ces workers prennent leur temps pour répondre aux requêtes (jusqu'à 3000ms sur le json du minichat). J'ai vérifié du coté d'uwsg et Django, sans rien voir d'anormal. Surtout que cela n'expliquerait pas les performances limitées du coté PHP aussi.

La DB n'est pas en surcharge non plus, j'ai 8 connexions simultanées autorisées, et baisser le timeout (pour les faire crasher plus rapidement) n'a rien changé. Ce n'est donc pas de là que ça vient.

J'ai lancé quelques tests, notamment sur des pages servies par PHP et n'utilisant pas de base de données (notamment la page d'accueil de PhpMyAdmin, qui est relativement légère), et j'ai des performances moyennes correctes, mais avec des gros pics par moment. J'en déduis donc que c'est quelque chose d'externe à ces outils...

En parallèle, j'ai pu constater des gros freezes dans ma connexion SSH avec le VPS. A nouveau, un top ne m'a pas permis d'identifier quoique ce soit, mais dans les logs du reboot de la machine, j'ai pas mal d'erreurs qui s'affichent (j'ai pas encore tout regardé). Je suspecte un potentiel problème matériel chez OVH, ou alors un abus de ressources de la part d'un autre client. Le hic, c'est que ça ne risque pas de s'arranger, vu mes expériences passées avec OVH, je sais de source sûre qu'ils vont m'envoyer vers un plan plus cher en rejetant la faute sur moi, plutôt que d'investiguer (ou même de surveiller leurs logs).

On verra comment ça se comporte à l'avenir, en croisant les doigts pour que ça soit une panne matériel, et que le matériel concerné lâche rapidement

Je poste aussi mon screenshot, du coup : https://lut.im/r2QdqYeC/r2dQox9E

La connection initiale peut prendre très longtemps (13 secondes ! et 7 pour la connection sur analytics.lexpage qui est un autre domaine), mais une fois la connection établie, ça va plutôt vite. C'est pas certain que le soucis vienne de ta VM, c'est peut être un soucis en amont.

Ce n'est pas impossible, mais des ping répétés n'ont rien révélés d'anormal au niveau réseau, même si avec l'infrastructure d'OVH, ce n'est pas toujours simple de savoir quel est le chemin pris par chaque requête.

Quoiqu'il en soit, n'hésitez pas à me faire remonter l'info quand le site présente des soucis de latence, en indiquant si possible l'heure exacte (y a le "page générée le xx mai 2015 à xx:xx:xx" en bas de page si vous voulez avoir l'heure du serveur).

Ayant rencontré à nouveau le même genre de soucis il y a quelques jours, j'ai finalement pris contact avec OVH. Selon eux, ce serait lié à un incident sur leur infrastructure (les détails du ticket parlent d'une attaque DDOS). Je n'y crois que moyennement, vu que ce n'est pas la première fois que ce type de soucis se posent sur le site, mais bon... on verra :)

Soucis il y a 2 minutes environ, grosse latence avant l'envoi des réponses, une fois la connection établie la vitesse était correcte.

RAS en ce moment-même.

Je les ai contactés car j'ai rencontré aussi des soucis. Ils me demandent de leur fournir (notamment) l'output de "top"... Je ne sais pas encore si je vais leur faire une vidéo Youtube ou leur expliquer l'idiotie de leur demande, mais je sais déjà que je m'engage dans un dialogue de sourds

En attendant, je vais déjà leur envoyer un diagnostique réseau + diagnostique du disque, ça épargnera des éventuelles futures requêtes de leur part...

Pareil, à l'instant près de 50 secondes pour charger la page la première fois et ensuite c'était rapide.

C'est quand même étrange, un soucis comme ça sur une première connection je dirais que ça vient du dns.

Je ne suis pas bien connaisseur dans ce domaine, mais est-ce que le fait d'avoir désactiver bind9 sur le serveur pourrait jouer un rôle ? (il est coupé depuis que le VPS est en prod, donc je doute que ça puisse avoir un impact, mais qui sait ?).

J'avais aussi mis en doute le firewall (qui limite le nombre de connexions par seconde par IP), mais les limites sont larges, et même désactivés, cela n'a rien changé.

Ce qui est "curieux", c'est que j'ai le même type de latence sur une connexion SSH parfois, cela ne vient donc pas directement de Nginx ou la stack derrière.

Si tu as la même lenteur sur ssh c'est intéressant, mais pas concluant. T'as plein de choses qui peuvent être lentes à l'établissement d'une connection ssh, mais tu peux quand même tester en mettant un "UseDNS no" dans ton /etc/ssh/sshd_config et voir si ça améliore les choses.

Accessoirement, c'est quoi comme VPS (quotas ram notamment)?

Je ne sais pas vraiment tester, puisque je ne peux pas reproduire systématiquement le problème. Il peut se poser quand je suis seul en ligne, ou quand on est 7-8. En général, quand j'ai les ralentissements en ligne, je saute sur SSH pour aller surveiller les logs et top, en espérant trouver quelque chose.

C'est le premier VPS dispo, qui culmine avec 1vCore (ce qui ne veut rien dire dans l'absolu) et 1 go de RAM. Je tourne à environ 500mo de mémoire utilisée (modulo le cache du disque). L'usage est très stable dans le temps : le CPU ne dépasse que rarement les 2-3% de charge en moyenne par seconde, avec des pics à 60-70% lorsque des requêtes sont traitées ou que je stresse Nginx, ce qui reste tout à fait raisonnable.