Bonjour,
Ce sujet a pour but d’améliorer le forum et de réparer les problèmes techniques rapportés par les utilisateurs.
Les membres ayant un background technique sont les bienvenus pour apporter leur idées et contributions.
Merci à tous,
Armel
Hébergement actuel
Concernant les problèmes de lenteur rencontrés récemment, toute aide est la bienvenue, voici quelques informations utiles :
> top
top - 15:11:27 up 2:15, 2 users, load average: 3.12, 3.53, 3.31
Tasks: 130 total, 4 running, 126 sleeping, 0 stopped, 0 zombie
%Cpu(s): 64.7 us, 12.2 sy, 0.0 ni, 10.1 id, 11.0 wa, 0.0 hi, 2.0 si, 0.0 st
KiB Mem : 4048268 total, 115392 free, 2324832 used, 1608044 buff/cache
KiB Swap: 1048572 total, 958336 free, 90236 used. 405230 avail Mem
> sar -W 1
03:15:09 PM pswpin/s pswpout/s
03:15:10 PM 0.00 40.00
03:15:11 PM 4.00 0.00
03:15:12 PM 7.00 0.00
03:15:13 PM 15.84 0.00
03:15:14 PM 0.00 34.00
03:15:15 PM 53.00 0.00
03:15:16 PM 68.00 0.00
03:15:17 PM 74.00 0.00
03:15:18 PM 0.00 50.00
03:15:19 PM 0.00 0.00
03:15:20 PM 8.00 0.00
03:15:21 PM 10.00 0.00
03:15:22 PM 682.00 40.00
03:15:23 PM 0.00 0.00
03:15:24 PM 5.00 0.00
03:15:25 PM 0.00 0.00
03:15:26 PM 214.85 0.00
03:15:27 PM 33.00 0.00
03:15:28 PM 0.00 0.00
03:15:29 PM 0.00 11.00
03:15:30 PM 0.00 0.00
Configuration app.yml
db_shared_buffers: "1GB"
db_work_mem: "40MB"
UNICORN_WORKERS: 4
Tu payes combien l’hébergement ??? ta machine ou est hébergé ton forum me semble bien faible …
Tu as 67% du Cpu occupé avec seulement 4 taches qui tournes sur 130 c’est énorme 
L’espace disque est remplit a combien actuellement ?
Et 4go de mémoire…cest juste sachant qu’un forum est ce qui mange le plus en requete sql.
Apres je connais pas trop ce type de forum sil est gourmand ou pas
Pour moi il est clair qu’il faut regarder du côté hébergement … en plus je pense qu’il y as pas que le forum sur ce serveur 
Il doit y avoir des logs pour voir les time out des requêtes SQL qui on échoués …
Si c’est un mutu cest different
Ca veut dire que d’autres sites sont crash… et que le soucis ne vient pas obligatoirement de ce forums alors…
Si c’est un dédié si
Sincèrement je pense pas que ce soit le forum mais plus du cote de l’hébergement , après je connais pas la structure du forum mais quand je vois 67% de cpu utilisé pour 4 taches en cours clairement ça peut pas fonctionner correctement après je pense que c’est du PHP / MySQL et déjà faut que le serveur soit a jour dans la version de PHP , ensuite un bon nettoyage de la base de données et ça roule … Si il y as aucune modification sur le forum et que ça c’est mis a déconner d’un coup c’est hébergement
Il peut aussi y avoir un problème de configuration d’un .Htaccess sur le ftp mais encore une fois dépend de la structure du forum et si @Armel a pas fait de modification sur le forum il n’y as aucune raison que ça merde
Problème de connexion time out c’est hébergeur
Oui si sur un Mutu les autres seront touché aussi mais ça il y as que l’hébergeur qui peut répondre …
Peut être faire un Dump de la base de donnée et que l’hébergeur regarde car c’est aussi son boulot de savoir pourquoi sa merde …moi quand j’ai une grosse galère que j’arrive pas a résoudre moi même j’ouvre un ticket et j’ai un technicien en moins de 2h 
et pourtant j’héberge pas en France 
Coucou.
Ingé système / devops a la rescousse !
11 de load c’est 4 fois trop : tes disques dur sont complètement noyés sous les requêtes et c’est normal que le SQL derrière soit a la traîne. Donc si c’est systématique comme mesure c’est là où tu vas pouvoir gagner beaucoup.
Le bon côté c’est que tu as encore un paquet de RAM libre et que donc tu devrais être en mesure de rajouter du cache sur ta base et/ou rajouter quelques index intelligent (mais il faudrait plus de détails et surtout profiler l’appli du forum pour savoir quoi faire).
Bref dans un premier temps augmenter le cache innodb de ta base et augmenter l’utilisation générale de la RAM pour soulager te disques semble pertinent.
Après si c’est du mutualisé tu risques de ne pas avoir beaucoup d’options de tuning sur le système et l’intégration…
Bon et je retire ce que j’ai dit sur le cache de la DB … visiblement t’as déjà 1g de cache qui fait son taf…
Faudrait un peu plus de détails pour mieux cerner ce qu’il se passe et avoir accès a un chouilla plus de stats que ça. Mais clairement tu es en manque de ressources
Si t’es sur Paris, on peut s’organiser une bouffe studieuse si tu veux
Bonsoir Armel,
Peux tu confirmer le mombre de core de la machine ? et si l hyperthreading est activé ? (
cat /proc/cpuinfo )
La machine ne semble pas super chargée ; il y a de la memoire dispo ; une bonne partie est meme utilisée pour faire du cach disk.
Concernant le CPU ; cela depend du nombre de coeur ( allez au hazard 2 coeur hyperthreadés ? )
peut on avoir un historique du top sur une periode de pointe ? ( met un truc du style :
top -b >> top-output.txt dans la crontab toutes les 2 ou 3 minutes )
Peux tu donner plus de detail sur ce qui tourne sur la machine ?
uniquement le forum ? Discourse + db postgress ? ( si postgress, peux tu fournir un certain nombre de pg_top durant une periode d activité/lenteur ) , quel est le webserver utilisé ?
J attend le resultat des top et l info sur le nombre de top , mais je ne serais pas surpris que ton server soit OK mais qu un des process ( postgress ou le webserver ? ) ai une limite de consommation memoir hardcodé (d ailleur tu as essayé de passer le app.yml db_shared_buffers a 2G ? )
et pour finir , ubuntu 18.04 est aussi une LTS , une upgrade pourrait faire du bien ! ( on n est pas sous windows , mais on ne sait jamais )
En tout cas a cette heure ci il tourne bien 
la solution est peut être de venir que la nuit
sar -d serait aussi interressant, regarder la latence disk , un SAN pourri ou surcharger et tout peut s effondrer .
C’est une vm ou une lame dédiée ?
Si vm, t’as le droit a combien de coeurs ?
Si dédié, le proc, c’est 4 coeurs, quel modèle ?
load average: 3.12, 3.53, 3.31
Ca vous choque pas ?
Concernant la db, c’est toi qui a sizé, par défaut clef en main ? Tu connais sa structure ?
Nop le load AVG a 3 c’est pas choquant plus que ça.
Mais sans métriques plus précises sur les requêtes/sec l’utilisation disque et les io wait ça va être compliqué de savoir si c’est les disques qui limitent la DB , le CPU qui est trop léger ou l’appli pas optimisée / mal configurée.
Idem…
A un moment donné, va falloir filer la main a un spécialiste système et db pour trouver la root cause… Pas assez d’info.
Moi si je compare avec mon hébergeur c’est vraiment le CPU qui me choque
Normalement ce service est dans l’offre de l’hébergeur quand c’est un hébergeur sérieux … tu ouvres un ticket en disant que tu as un sérieux problème et eux agissent …je connais pas du tout cet hébergeur mais si ce genre de service n’est pas compris faut fuir ou être certain d’avoir toutes les compétences pour pouvoir faire face a tout les problèmes tout seul
Croissance organique qu’on appelle ça chez nous … Des fois y a pas de soucis, mais juste une utilisation accrue, plus de visite, plus de contenu … Et faut scaler ! (Donc sortir les sousous de la popoche)
Mais la ça sert a rien de tergiverser parce qu’il pourrait s’agir de tout et n’importe quoi … CPU, disque , config mal branlée … appli a chier , requêtes SQL trop grosses / trop longues , pas assez de cache etc…
Donc on peut pas en dire beaucoup plus.
(Juste digital ocean c’est pas des branleurs normalement)
Ah je savais pas, je n’ai pas trop l’habitude des offres grand public.
Ben, faut que Armel ouvre un ticket au support alors…et d’urgence!!
Ptete qu’il a juste une vm vierge avec qqes spec, point barre, et pas de support système.
Mais comme on n’as pas plus info que ca…ca sert a rien de spéculer.