L'utilisation de la mémoire augmente progressivement après le redémarrage

Installation
1

Je ne suis pas sûr quand cela a commencé, mais à un moment donné au cours des dernières semaines, probablement après une mise à jour de Discourse, le site a commencé à sembler un peu lent. Nous utilisons la version 3.4.0.beta2-dev.

J’ai remarqué que l’instance du serveur n’avait presque plus de mémoire libre, alors je l’ai redémarrée. Après le démarrage de Discourse, l’utilisation de la mémoire était initialement correcte (environ 1,2 Go), mais elle a commencé à augmenter et semble sur le point d’atteindre un point où elle redeviendra lente.

Le site n’est pas particulièrement fréquenté (20 à 30 visiteurs par jour) et il a bien fonctionné pendant de nombreuses années, jusqu’à récemment.

L’instance du serveur dispose de 2 Go de mémoire, ce qui devrait être suffisant selon les exigences que j’ai vues (1 Go minimum ; 2 Go recommandés).

J’ai l’impression qu’il s’agit d’une fuite de mémoire. Bien sûr, s’il y a une fuite, ce n’est peut-être pas Discourse, mais Docker ou autre chose. L’instance n’est utilisée que pour Discourse.

Des idées ? Existe-t-il un moyen de vérifier qu’il s’agit d’une fuite et d’identifier le processus qui la cause ?

2

La mémoire libre est un concept très fuyant - le seul signe certain de mémoire insuffisante est l’activité de pagination.

free
ou
free -h
vous donnera un instantané

vmstat 5 5
est très utile pour voir comment les choses se passent, y compris l’activité de pagination.

2 « J'aime »
3 
              total        used        free
Mem:          1.9Gi       1.5Gi        73Mi
Swap:         2.0Gi        54Mi       1.9Gi

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0  55524 111624  20080 385060    1    3    68    52  965  349  4  2 93  1  0
 0  0  55524 114884  20088 385152    0    0    13     8 1047  352  2  1 96  0  0
 0  0  55524 112428  20088 385160    0    0     0     3  831  319  3  1 95  0  0
 0  0  55524 111616  20096 385164    0    0     0    51  688  278  2  0 97  0  0
 0  0  55524 109884  20104 385168    0    0     0     8 1117  281  2  1 96  0  1

Quelque chose vous semble-t-il problématique dans ce qui précède ? J’obtiens les chiffres d’utilisation de la mémoire de HTOP, qui semblent correspondre à FREE.

Ma principale préoccupation est la façon dont l’utilisation de la mémoire continue de croître. Je m’attendrais à ce qu’elle atteigne un certain point, puis qu’elle oscille autour de ce point, augmentant et diminuant avec l’utilisation du site. La tendance constante à la hausse est décourageante.

4

certainement, cela semble correct pour le moment - aucune activité dans si et so, qui est la pagination, et aussi très peu de trafic disque, qui est bi et bo.

ce que Linux fait, c’est utiliser la mémoire libre pour la mise en cache du disque, il n’est donc pas mauvais de voir la mémoire libre diminuer. La sortie de free montre la RAM disponible, la page man dit :

available
Estimation de la quantité de mémoire disponible pour le démarrage de nouvelles applications, sans échange.

Dans le cas de vmstat, les colonnes buff et cache correspondent à la mémoire utilisée pour la mise en cache du disque et peuvent augmenter pour améliorer les performances d’E/S, mais diminuer en cas de pression sur la mémoire. Ainsi, pour free et vmstat, le montant « gratuit » est une mesure pessimiste.

1 « J'aime »
5

D’accord, merci. La lenteur n’était peut-être pas liée à ce qui semblait être une situation de faible mémoire. Je continuerai à surveiller cela.

1 « J'aime »
6

Il est toujours possible que quelque chose prenne progressivement de l’ampleur.

Voici l’une de mes tactiques pour voir ce qui se passe :

# ps aux|sort -n +5|tail
systemd+    1659  0.0  1.3 904384 54588 ?        S    16:44   0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
root         830  0.0  1.6 2253324 65208 ?       Ssl  16:44   0:01 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
systemd+    1682  0.0  1.9 904516 78092 ?        Ss   16:44   0:01 postgres: 13/main: checkpointer 
systemd+    18757  0.1  2.1 912368 85644 ?        Ss   18:06   0:00 postgres: 13/main: discourse discourse [local] idle
1000        1688  0.1  6.5 1006548 256428 ?      Sl   16:44   0:10 unicorn master -E production -c config/unicorn.conf.rb
1000        2189  0.1  8.5 5657760 333248 ?      Sl   16:45   0:06 unicorn worker[3] -E production -c config/unicorn.conf.rb
1000        2113  0.1  8.5 5656608 334352 ?      Sl   16:45   0:07 unicorn worker[2] -E production -c config/unicorn.conf.rb
1000        2044  0.4  8.7 6052196 342380 ?      Sl   16:44   0:23 unicorn worker[1] -E production -c config/unicorn.conf.rb
1000        2006  1.7  9.0 5628640 352492 ?      Sl   16:44   1:33 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  3.1 11.1 6033652 435388 ?      SNl  16:44   2:54 sidekiq 6.5.12 discourse [0 of 5 busy]

(ou ps auxc)

2 « J'aime »
7

S’il est facile de surveiller l’activité du processeur et des E/S (disque), je recommanderais de surveiller ces éléments plutôt que l’utilisation de la mémoire. Surtout les E/S. Si le processeur est bas et les E/S sont élevées, et que le forum est lent, cela pourrait indiquer une pénurie de RAM qui a un impact.

8

Quelques raisons, autres qu’un bug, pour qu’un site devienne lent : l’une est une augmentation progressive des utilisateurs, de l’activité des utilisateurs, de la taille de la base de données ; l’autre est que Discourse devient de plus en plus grand à mesure qu’il se développe, ajoute des fonctionnalités, met à jour des composants logiciels.

Mais il est utile de garder un œil sur la réactivité et sur la bonne dimension de la machine actuelle.

(Soit dit en passant, je remarque que la machine la moins chère de Hetzner dispose désormais de 4 Go de RAM, au même prix que la machine la moins chère désormais indisponible qui dispose de 2 Go de RAM. L’un de mes sites fonctionne toujours sur l’ancienne taille de 2 Go.)

Pour mémoire, comme j’ai suivi l’utilisation de mon site principal, puisqu’il a été récemment migré et que le serveur est neuf et fraîchement redémarré, j’inclurai quelques observations. C’est beaucoup de données - n’hésitez pas à ne pas les étudier !

L’état actuel de la machine est

# uptime
 13:55:23 up 4 days, 21:10,  1 user,  load average: 0.07, 0.08, 0.02
# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1638012       98492      481864     2168840     1595004
Swap:        4194288      252928     3941360

Je remarque qu’à la connexion, la machine annonce
Memory usage: 45%
ce qui reflète le plus étroitement la colonne ‘used’, pas la colonne ‘free’.

J’ai pris des relevés périodiques des commandes suivantes

   date
   uptime
   free
   ps aux|sort -n +5|tail
   vmstat 5 5

et ce que j’ai vu, c’est que la mémoire ‘free’ a été échangée contre la mémoire ‘buffer’ et ‘cache’, sans que l’empreinte RAM des processus (RSS) n’augmente. Je pense que cela montre pourquoi il n’est pas idéal de suivre la mémoire ‘free’, même si certains fournisseurs d’hébergement le facilitent. Je pense que cela montre aussi, dans ce cas, aucune fuite de mémoire.

Peu de temps après le redémarrage, je vois ceci :

# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1560508      996400      179712     1348436     1974692
Swap:        4194288           0     4194288

et peu de temps après

# ps aux|sort -n +5|tail
...
1000        1688  0.1  6.5 1006548 256428 ?      Sl   16:44   0:10 unicorn master -E production -c config/unicorn.conf.rb
1000        2189  0.1  8.5 5657760 333248 ?      Sl   16:45   0:06 unicorn worker[3] -E production -c config/unicorn.conf.rb
1000        2113  0.1  8.5 5656608 334352 ?      Sl   16:45   0:07 unicorn worker[2] -E production -c config/unicorn.conf.rb
1000        2044  0.4  8.7 6052196 342380 ?      Sl   16:44   0:23 unicorn worker[1] -E production -c config/unicorn.conf.rb
1000        2006  1.7  9.0 5628640 352492 ?      Sl   16:44   1:33 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  3.1 11.1 6033652 435388 ?      SNl  16:44   2:54 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0      0 866112 314288 1083816    0    0    32    28  484  621  4  1 95  0  0

Vous voyez que sidekiq (435 Mo) et les unicorns (330-350 chacun) sont les plus gros processus.

Au fil du temps, la RAM libre puis l’utilisation de la RAM de sidekiq (RSS) diminuent, probablement en raison de la pagination, sans effet indésirable - la machine ne montre aucune activité de pagination. En faveur d’un espace tampon et cache accru, je pense.

# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0      0 679764 326988 1190840    0    0     0    11  285  396  1  1 98  0  0

Environ 14 heures plus tard :

# uptime
 10:12:06 up 17:27,  1 user,  load average: 0.04, 0.02, 0.00
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.6 5647908 377424 ?      Sl   Sep05  12:42 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.8 11.3 6431988 444184 ?      SNl  Sep05  18:51 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0   2048 199972 342480 1576156    0    0     0    17  361  511  2  2 96  0  0

Plus tard…

# uptime
 19:52:00 up 1 day,  3:07,  1 user,  load average: 0.02, 0.06, 0.01
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.8 5654308 382944 ?      Sl   Sep05  20:44 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.5 11.1 6431668 436340 ?      SNl  Sep05  25:04 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0   2304 103356 301632 1690136    0    0     0    10  360  511  1  1 98  0  0

Plus tard…

# uptime
 12:13:09 up 1 day, 19:28,  2 users,  load average: 0.05, 0.06, 0.01
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.1 5654820 358612 ?      Sl   Sep05  31:47 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.3 10.0 6431668 393584 ?      SNl  Sep05  35:08 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0 284416 281596  77904 1908528    0    0     0    38  315  450  1  1 98  0  0

Plus tard

# uptime
 13:26:42 up 2 days, 20:42,  1 user,  load average: 0.20, 0.06, 0.02
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.3 5789072 365720 ?      Sl   Sep05  51:54 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.2 10.0 6433332 393472 ?      SNl  Sep05  50:44 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0 242944  82016  95188 2082180    0    0     0   131  332  488  1  1 98  0  0

Plus tard

# uptime
 09:21:33 up 3 days, 16:36,  1 user,  load average: 0.13, 0.10, 0.03
# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1618936      323032      476664     1963376     1619208
Swap:        4194288      250112     3944176
# ps aux|sort -n +5|tail
...
1000        2006  1.2  9.3 5789200 363572 ?      Sl   Sep05  67:02 unicorn worker[0] -E production -c config/unicorn.conf.rb
1000        1971  1.1  9.6 6433652 377472 ?      SNl  Sep05  63:14 sidekiq 6.5.12 discourse [0 of 5 busy]
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 0  0 250112 321888  56052 1906672    0    0     2    13  293  420  1  0 99  0  0

Plus tard

# uptime
 13:55:23 up 4 days, 21:10,  1 user,  load average: 0.07, 0.08, 0.02
# free
               total        used        free      shared  buff/cache   available
Mem:         3905344     1638012       98492      481864     2168840     1595004
Swap:        4194288      252928     3941360
# ps aux|sort -n +5|tail
...
1000        1971  1.1  9.5 6434676 371648 ?      SNl  Sep05  80:49 sidekiq 6.5.12 discourse [0 of 5 busy]
1000        2006  1.2  9.5 5658468 373404 ?      Sl   Sep05  88:44 unicorn worker[0] -E production -c config/unicorn.conf.rb
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
...
 1  0 252928 101040  86736 2082372    0    0     0    10  333  482  1  0 99  0  0
9

Merci d’avoir partagé vos observations. Je constate à peu près la même chose, sauf que nous utilisons une instance de 2 Go, il y a donc moins de marge de manœuvre. Merci également d’avoir souligné que certaines mesures de la mémoire « libre » et « utilisée » ne sont pas nécessairement utiles.

Lors de mon dernier redémarrage de l’instance il y a quelques jours, l’utilisation initiale de la mémoire était de 1,23 Go. Depuis, elle a progressivement augmenté et atteint maintenant 1,8 Go. Le site reste raisonnablement réactif, pour l’instant.

Le site n’a en fait pas beaucoup d’utilisateurs, et il n’y a pas eu d’augmentation récente des inscriptions ou de l’activité des utilisateurs. Au cours du dernier mois, il y a eu environ 20 nouveaux sujets, une centaine de messages et environ 4 utilisateurs actifs par jour.

Je continuerai à surveiller la situation et publierai ici si la mémoire de l’instance atteint à nouveau son maximum, ou si le site devient à nouveau lent, ou les deux.

1 « J'aime »
10

La mise à niveau de Discourse devenait une corvée en raison de problèmes de mémoire, nous avons donc finalement mis à niveau la machine virtuelle de 2 Go à 4 Go. Depuis lors, l’utilisation de la mémoire s’est stabilisée.

2 « J'aime »