L'installation de Discourse est devenue de plus en plus lente

Mon installation Discourse est devenue de plus en plus lente ces dernières semaines. Par le passé, lorsque cela se produisait, la reconstruction de l’application aidait. Cependant, cela ne semble plus aider.

J’ai cherché des conseils sur ce forum et j’ai essayé quelques optimisations de la base de données (vacuum full verbose, rebuild index, vacuum analyze verbose).

Cependant, rien ne semble aider, et lorsque je démarre le conteneur, il faut beaucoup, beaucoup de temps avant que je puisse réellement me connecter au forum.

Si cela continue, le forum deviendra à terme complètement inutilisable. Avez-vous une idée par où commencer à chercher ?

3 « J'aime »

Quelle est la taille de votre base de données ? Quelle quantité de RAM possédez-vous ?

1 « J'aime »

La sortie de

vmstat 5 5

pourrait être utile ici. (Exécutez-la au moment où le problème se produit !)

2 « J'aime »

Mémoire disponible : (depuis top)

iB Mem :  4041756 total,   108980 free,  3834244 used,    98532 buff/cache
KiB Swap:  1949692 total,   972196 free,   977496 used.    31140 avail Mem 

Sortie Vmstat : (lorsque j’essaie de charger des choses, ce qui fonctionne très très lentement)

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st\n 9  2 1011424 108300  15308 122392   37   32   145   101    0    0  2  3 93  1  0\n 5  2 1028312 114696   9976 101252 2104 3904  2176  3915  340 1939 41 38  1 19  0\n 2  4 1054116 115892  10196 102260 1378 6803  4171  6826  870 1812 23 28  1 48  0\n 0  4 1011420 257496  10860 108464 3427 3937  6223  3969  829 2788 15 28  2 55  0\n 6  2 1001844 154328  12988 120800 4366  124  7166   161  742 2947 14 26  2 58  0\nhubbe@tymin:~$ vmstat 5 5\nprocs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st\n 1  4 1004748  85768  13948 114648   37   32   145   101    0    0  2  3 93  1  0\n 0  6 1033260 108584  10212 101668 1566 6661  4368  6807  497 1990 11 27  0 61  0\n12  7 1050808  99524  10708  94852 1932 4551  4854  4625  660 2263 24 32  2 42  0\n 5  8 1078776 125060   9136  92948 2079 6963  5541  7030  771 2040 17 32  0 51  0\n 4  3 1004784 168216  10164 103420 2631 1457  4970  1467  617 2136 34 38  1 27  0\n```

PS : mon site est disponible ici si cela peut aider : https://crucible.hubbe.net/

[quote="Jay Pfaffman, post:2, topic:260501, username:pfaffman"]
Quelle est la taille de votre base de données ?
[/quote]

Comment puis-je vérifier ?
1 « J'aime »

Est-ce que Discourse est la seule chose sur ce serveur ? Combien de licornes avez-vous configurées dans le fichier app.yml ?

2 « J'aime »

Ce n’est pas la seule chose, mais c’est certainement la plus importante.

Voici les principaux processus par utilisation de la mémoire :

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                       
 1818 hubbe     20   0  910068 159724  10272 S   0.0  4.0   0:31.17 ruby                                                                          
 6141 hubbe     25   5 1195492 140180  10080 S   4.2  3.5  11:31.61 ruby                                                                          
 1845 hubbe     20   0  908732 124036   9388 S   2.8  3.1   0:29.94 ruby                                                                          
 1780 hubbe     20   0  910076  82072   3796 S   0.0  2.0   0:28.40 ruby                                                                          
 1937 systemd+  20   0  360060  25632  21076 S   0.0  0.6   0:00.86 postmaster                                                                    
 2134 systemd+  20   0  356020  23608  19760 S   0.0  0.6   0:00.13 postmaster                                                                    
 1797 systemd+  20   0  355840  22620  19404 S   1.4  0.6   0:00.75 postmaster                                                                    
 2092 systemd+  20   0  356288  21644  17584 S   0.0  0.5   0:00.17 postmaster                                                                    
 2063 systemd+  20   0  355984  18364  16504 S   0.0  0.5   0:00.20 postmaster                                                                    
 1939 systemd+  20   0  355904  15668  15232 S   0.0  0.4   0:00.25 postmaster                                                                    
 2131 systemd+  20   0  353948  14804  13000 S   0.0  0.4   0:00.02 postmaster                                                                    
38770 root      20   0  689760  12940      0 S   0.0  0.3 434:00.34 dockerd                                                                       
43876 root      20   0   16492   9428   1608 S   0.0  0.2   3:34.89 roxen                                                                         
 5728 hubbe     20   0  574796   8136   2064 S   0.0  0.2   0:58.94 ruby                                                                          
37533 root      20   0  593420   5848   1020 S   2.8  0.1 539:40.11 containerd                                                                    
 5689 systemd+  20   0   96432   5832   1672 S   0.0  0.1   3:54.43 redis-server                                                                  
 2196 www-data  20   0  166248   4924   2580 S   0.0  0.1   1:18.03 nginx                                                                         
 2197 www-data  20   0  165972   4484   3168 S   0.0  0.1   1:29.32 nginx                                                                         

Presque tout sur cette liste, à l’exception de roxen, est lié au discours.

UNICORN_WORKERS est commenté dans mon app.yml

Il semble que la sauvegarde d’un article soit particulièrement sujette aux interruptions et aux échecs.
Je ne suis pas sûr que cela puisse donner un indice sur ce qui se passe.

La sortie de vmstat nous indique que, dans l’état actuel des choses, il n’y a pas assez de RAM.

Il se peut que Discourse fonctionne comme il se doit, et que tout soit en ordre, mais que vos données aient atteint un point où 4 Go de RAM ne suffisent plus.

Ou il se peut que quelque chose ait mal tourné et qu’une grande quantité de RAM soit utilisée alors qu’elle ne devrait pas l’être.

Une mesure de la taille consiste à faire une sauvegarde sans les pièces jointes et à voir sa taille.

Il se peut que le mini-profiler donne un indice sur les actions de base de données qui prennent tant de temps.

Si vous avez le budget pour doubler la RAM, faites-le. (Si vous prenez soin d’augmenter la RAM tout en laissant le stockage tel quel, si vous avez une telle option de la part de votre fournisseur, alors cela peut être un changement réversible, voire temporaire.)

5 « J'aime »

C’est exact.

Si vous ne pouvez pas vous permettre plus de RAM, vous pouvez essayer de définir des valeurs plus basses pour db_shared_buffers (par exemple, 128 Mo ou moins) et limiter UNICORN_WORKERS à seulement 2 en attendant, car vous devez arrêter le swapping dès que possible.

3 « J'aime »

62,5 Mo

Plus de RAM est assez cher de la part de mon fournisseur d’hébergement, je vais donc d’abord explorer d’autres options. (Et je crains que le modifier ne casse mon prix « grand-père »…)

J’ai changé db_shared_buffers en 128 Mo et UNICORN_WORKERS en 2.
Est-ce que launcher app stop / start suffit pour que ces paramètres prennent effet ?

Qu’est-ce que le mini-profiler et comment l’utiliser ?

1 « J'aime »

Avec un Alt+P sur votre clavier, les actions ultérieures sur le forum devraient afficher une chaîne de temps juste sous la bannière du forum (pour moi, à droite) et si vous cliquez sur le temps, vous verrez une fenêtre contextuelle avec quelques statistiques.

C’est à peu près la même chose que la mienne, fonctionnant avec 1 Go de RAM. J’ai 2 000 sujets, 15 000 messages, plus de 500 inscriptions.

Quelle est l’historique de votre Discourse ? Je me souviens vaguement d’une époque où il était censé créer un index pour une table pour des raisons de performance.

Qu’en est-il des plugins ? Pouvez-vous exécuter des actions en mode sans échec pour voir si elles s’exécutent plus rapidement ?

2 « J'aime »

Il pourrait également être utile de coller votre arborescence de processus complète :

ps auxf

J’ai posté la mienne ici
Demande d’aide pour l’installation de discourse

1 « J'aime »

Existe-t-il un endroit facile pour trouver ces statistiques ?
La plupart des statistiques que je vois me montrent ce qui s’est passé au cours de la dernière journée ou semaine, mais aucun total.

Je ne suis pas sûr de ce que vous entendez par historique. Mais je l’ai commencé en mars 2021.

Première impression : le mode sans échec n’est pas plus rapide. Je vais jouer avec et le mini-profiler pour voir si cette impression se confirme.

Sortie de ps auxf ci-jointe.
auxf.txt (20,1 Ko)

1 « J'aime »

Sur la page /about, il y a une colonne pour le tout-temps.

Il semble que votre machine n’ait pas été redémarrée depuis plus d’un an - il serait probablement utile de le faire, et de mettre à jour pour la sécurité en même temps. Il est tout à fait possible que le redémarrage aide.

1 « J'aime »

Je pense avoir remarqué que votre serveur est configuré pour utiliser un hyperviseur alors que le mien est configuré pour utiliser LXC. Je ne sais pas si c’est important. (Mon système affiche un processus /usr/bin/lxcfs que le vôtre n’a pas, et le vôtre affiche un processus hv_vss_daemon que le mien n’a pas.)

Aussi, peut-être pourriez-vous partager la sortie de df -T et swapon.

1,3k sujets, 24,7k messages, 631 inscriptions, 7,1k mentions J’aime

redémarrer les machines Linux n’aide généralement à rien, mais je suppose que je peux essayer.

Je suis d’accord avec une attitude sceptique à ce sujet ! Mais je ne le suggère pas à la légère - je suis à peu près sûr que nous avons vu un cas où un système fonctionnant depuis longtemps s’est amélioré avec un redémarrage. (Edit : ici, bien que ce soit un cas différent.)

Voici ce que le mini-profiler a dit pour la sauvegarde d’un article :

Cela a pris environ 30 secondes.