Depuis la reconstruction d’aujourd’hui, nous rencontrons un grand nombre d’erreurs serveur. Il semble s’agir d’un problème de connexion nginx ; dans nginx/error.log, je vois parfois des rafales de messages 768 worker_connections are not enough comme celui-ci :
2021/06/02 10:42:21 [alert] 1143#1143: *28468 1768 worker_connections are not enough while connecting to upstream, client: (IP removed), server: _, request: "POST /message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t HTTP/1.1", upstream: "http://127.0.0.1:3000/message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t", host: "blenderartists.org", referrer: "https://blenderartists.org/t/convert-multiple-objects-to-single-mesh-with-vertex-grouping/489173/2"
Avez-vous des idées pour remédier à cela ? Nous avons beaucoup de CPU et de mémoire disponibles — pourrions-nous augmenter le nombre de ‘worker connections’ ?
Mise à jour : j’ai temporairement augmenté le nombre de connexions par worker, mais je rencontre toujours ces erreurs (moins fréquemment et avec un nombre plus élevé de workers). Je suis vraiment curieux de savoir si quelque chose a changé récemment et pourrait en être la cause, ou comment je pourrais mieux investiguer ce problème.
## Commandes personnalisées à exécuter après la construction
run:
- exec: echo "Début des commandes personnalisées"
- replace:
filename: "/etc/nginx/letsencrypt.conf"
from: "worker_connections 768"
to: "worker_connections 1768"
C’est intéressant que cela se soit produit après une reconstruction. Avez-vous récemment effectué des actions en masse ? Je vérifierais les journaux Sidekiq pour voir s’il y a également un grand nombre de tâches.
J’ai effectivement eu quelques actions groupées récemment lors de notre passage à l’aperçu de vignettes TC, mais il n’y a rien dans ma file d’attente Sidekiq, je peux donc l’exclure avec certitude.
Je n’en ai aucune idée — peut-être ? Avez-vous des idées sur la façon de vérifier cela ?
C’est exact. Mais j’ai désactivé toute accélération et j’utilise essentiellement Cloudflare uniquement pour mettre en cache les images et les avatars. Cela n’a jamais posé de problème jusqu’à aujourd’hui.
Haha, généralement, les gens utilisent Google Analytics ou quelque chose de similaire pour connaître ce genre d’informations. Le tableau de bord de Discourse affiche les pages vues quotidiennes et les visites d’utilisateurs, ce qui peut aussi servir à estimer cela.
Ce n’est pas exact, votre site entier est servi via Cloudflare :
Cependant, cela peut être complètement sans rapport, car votre nginx se plaint des connexions amont (upstream) plutôt que des connexions aval (downstream), ce qui signifie qu’il manque de connexions entre nginx ⟷ unicorn.
Puisque nous maintenons une connexion ouverte pour chaque visiteur grâce à message_bus (service de mises à jour en direct), c’est en quelque sorte attendu si votre site est quelque peu populaire.
Augmenter worker_processes et worker_connections est sans danger et semble logique dans votre cas. Par défaut, worker_processes est défini sur le nombre de cœurs de votre CPU. Combien de cœurs CPU avez-vous ?
C’est vrai Nous avons abandonné cela il y a longtemps… Nous avons environ 250 000 vues de page par jour (bots inclus), donc 500 ne semble pas inhabituel. Les visites d’utilisateurs ne suivent-elles que les connexions des utilisateurs authentifiés, c’est bien ça ?
Exact — nous devons bien faire passer nos requêtes par CF, mais nous ne leur permettons pas de modifier notre JavaScript, etc.
Nous avons 12 cœurs et 64 Go de RAM. La charge typique est d’environ 2, et nous utilisons 50 % de notre mémoire vive.
La formule pour les connexions est worker_processes * worker_connections, ce qui devrait donner 12 * 768, soit (clac clac) 9216. Mais vos journaux indiquent 1768…
Essayez ceci dans votre fichier app.yml :
## Toute commande personnalisée à exécuter après la construction
run:
- exec: echo "Début des commandes personnalisées"
- replace:
filename: "/etc/nginx/nginx.conf"
from: "worker_connections 768"
to: "worker_connections 2000"
- replace:
filename: "/etc/nginx/nginx.conf"
from: "worker_processes auto"
to: "worker_processes 10"
Sachez que votre bloc dans le message 2 agit sur le mauvais fichier !
Exactement. Nous avons également augmenté la valeur par défaut à 4k dans le même correctif, les administrateurs pourraient donc vouloir évaluer attentivement s’ils ont toujours besoin de l’augmenter.
Nous avons abandonné cela il y a longtemps… Nous avons environ 250 000 vues de page par jour (bots inclus), donc 500 ne semble pas inhabituel. Les visites d’utilisateurs ne suivent-elles que les connexions des utilisateurs authentifiés, c’est bien ça ?
J’ai collé le mauvais code - j’ai d’abord essayé le modèle letsencrypt, mais j’ai fini par modifier nginx.conf pour passer à 1768 connexions worker.