hostname ip-172-x-x-x-app
process_id 286281
application_version 3532c825824ee1259628545c7bd5311ecb918009
current_db default
current_hostname discussion.mcebuddy2x.com
message Lors du tic du gestionnaire de planification
time 19 h 57
Cela serait probablement dû à une limitation des ressources de votre serveur. Que fait la RAM en ce moment ? Avez-vous des détails sur le droplet que vous exécutez ?
Quand avez-vous dernièrement mis à niveau Docker, le système d’exploitation et l’image Discourse ? Est-ce que tout cela fonctionne avec la dernière version sur les trois ?
Tout fonctionnait correctement dans la version bêta de il y a quelques semaines. Ce problème est apparu après la mise à jour de la version bêta vers la version stable via l’option de mise à jour dans le navigateur.
cela affiche le nombre maximal de processus/threads utilisateur autorisés.
ulimit -a
cela affiche toutes les limites de ressources.
cat /sys/fs/cgroup/pids.max
cela vérifie le nombre maximal de processus (PIDs) autorisés pour le cgroup du conteneur ou du système.
Ensuite, utilisez logout pour revenir à l’hôte ;
systemctl show docker | grep TasksMax
cela vérifie si systemd a imposé une limite de tâches/threads au service Docker.
systemctl show containerd | grep TasksMax
cela effectue le même type de vérification, mais pour le service containerd plutôt que pour Docker directement.
docker inspect app | grep -i pid
cela vérifie les limites et paramètres de processus/PID de votre conteneur Discourse. Le grep -i pid : filtre tout ce qui contient « pid » (sans distinction de casse).
Si vous continuez à rencontrer des erreurs, pourriez-vous s’il vous plaît copier-coller ici la sortie de ces commandes, cela serait très utile.
Une reconstruction depuis l’interface de ligne de commande semble avoir résolu le problème. Je vais continuer à surveiller la situation. Il semble que la mise à jour du navigateur, passant de la version bêta à la version stable au cours de la dernière semaine, ait déclenché ce souci.
Devrait-il y avoir des limites imposées à la mise à niveau du navigateur ? La mise à niveau du navigateur peut-elle détecter d’éventuels problèmes, les signaler ou empêcher le déclenchement de la mise à niveau ?
La reconstruction a probablement réinitialisé le placement du cgroup du conteneur, ce qui expliquerait pourquoi il est à nouveau stable.
Compte tenu des erreurs originales « can’t alloc thread » et du fait que tout le reste (ulimits, TasksMax, PIDs Docker) est illimité, le principal suspect restant est la pression du cgroup PID.
Pourriez-vous vérifier lors d’une charge normale :
Si pids.current approche de ~2000+ par rapport à un maximum de ~2285, cela confirmerait que le conteneur atteignait le plafond PID du cgroup lors des rafales de reconnexion du planificateur / Redis.
Cela expliquerait également pourquoi le problème n’est apparu qu’après la mise à niveau (changement accru de threads) et pourquoi la reconstruction l’a temporairement résolu.
Nombre de processus (PIDs/fils d’exécution) actuellement en cours d’exécution dans le conteneur/cgroup ↩︎
Nombre maximal de processus (PIDs/fils d’exécution) autorisés dans ce cgroup (votre conteneur) ↩︎
Merci : cela permet d’éliminer une pression actuelle des PID après la reconstruction.
Étant donné que pids.current n’est que de 227 contre 4194304, le conteneur est définitivement loin du plafond de PID du cgroup à présent.
Le point intéressant est que pids.max affichait auparavant 2285, alors qu’il est désormais 4194304 après la reconstruction. Il est donc probable que la reconstruction ait réinitialisé la limite du cgroup (c’est-à-dire qu’elle ait renouvelé le conteneur d’application), ce qui explique l’absence de preuve d’un problème actif d’épuisement des PID pour le moment.
Si l’erreur réapparaît, il serait utile de copier-coller les commandes suivantes au moment où l’échec se produit :
cat /sys/fs/cgroup/pids.current
cat /sys/fs/cgroup/pids.max
ps -eLf | wc -l
Cela permettrait de déterminer si l’échec est dû à une pression des PID, ou s’il faut chercher ailleurs
