El uso de memoria aumenta gradualmente después del reinicio

Instalación
1

No estoy seguro de cuándo empezó, pero en algún momento de las últimas semanas, presumiblemente después de una actualización de Discourse, el sitio empezó a sentirse un poco lento. Estamos ejecutando 3.4.0.beta2-dev.

Noté que la instancia del servidor casi no tenía memoria libre, así que la reinicié. Después de que Discourse se inició, el uso de memoria fue inicialmente bueno (alrededor de 1.2 GB), pero comenzó a aumentar y parece probable que pronto alcance un punto en el que vuelva a ser lento.

El sitio no está particularmente ocupado (20 a 30 visitantes diarios), y ha estado bien durante muchos años, hasta hace poco.

La instancia del servidor tiene 2 GB de memoria, lo que debería ser suficiente según los requisitos que he visto (1 GB mínimo; 2 GB recomendado).

Me parece más bien una fuga de memoria. Por supuesto, si hay una fuga, puede que no sea Discourse, sino Docker o algo más. La instancia solo se utiliza para Discourse.

¿Alguna idea? ¿Hay alguna forma de verificar que es una fuga e identificar el proceso que la causa?

2

La memoria libre es un concepto muy resbaladizo; el único signo seguro de que hay muy poca memoria es la actividad de paginación.

free
o
free -h
te dará una instantánea.

vmstat 5 5
es muy útil para ver cómo van las cosas, incluida la actividad de paginación.

2 Me gusta
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

¿Algo de lo anterior parece problemático? He estado obteniendo números de uso de memoria de HTOP, que parecen coincidir con FREE.

Mi principal preocupación es la forma en que el uso de la memoria sigue creciendo. Esperaría que llegara a cierto punto y luego se mantuviera alrededor de allí, subiendo y bajando con el uso del sitio. La tendencia constante al alza es desconcertante.

4

cierto, eso parece estar bien por el momento; no hay actividad en si y so, que es paginación, y también muy poco tráfico de disco, que es bi y bo.

lo que hace Linux es usar la memoria libre para el caché de disco, por lo que no está mal ver que la memoria libre disminuye. La salida de free muestra la RAM disponible, la página del manual dice:

disponible
Estimación de cuánta memoria está disponible para iniciar nuevas aplicaciones, sin intercambio.

En el caso de vmstat, las columnas buff y cache son memoria utilizada para el caché de disco y pueden crecer para mejorar el rendimiento de E/S, pero se reducen cuando hay presión de memoria. Por lo tanto, tanto para free como para vmstat, la cantidad ‘libre’ es una medida pesimista.

1 me gusta
5

De acuerdo, gracias. Posiblemente la lentitud no estaba relacionada con lo que parecía ser una situación de baja memoria. Continuaré monitoreando esto.

1 me gusta
6

Todavía es posible que algo esté creciendo gradualmente.

Esta es una de mis tácticas para ver qué está pasando:

# 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]

(o ps auxc)

2 Me gusta
7

Si es fácil monitorear la actividad de la CPU y de E/S (disco), recomendaría vigilar esas, en lugar del uso de memoria. Especialmente la E/S. Si la CPU está baja y la E/S está alta, y el foro va lento, eso podría indicar una escasez de RAM que tiene un impacto.

8

Un par de razones, además de un error, por las que un sitio se vuelve lento: una es el aumento gradual de usuarios, actividad de usuarios, tamaño de la base de datos; la otra es que Discourse se hace cada vez más grande a medida que se desarrolla, agrega funciones y actualiza componentes de software.

Pero vale la pena vigilar la capacidad de respuesta y si la máquina actual tiene el tamaño adecuado.

(De paso, noto que la máquina más barata de Hetzner ahora tiene 4G de RAM, al mismo precio que la máquina más barata ahora no disponible que tiene 2G de RAM. Uno de mis sitios todavía se ejecuta en el tamaño anterior de 2G).

Para que conste, ya que he estado rastreando el uso de mi sitio principal, dado que fue migrado recientemente y el servidor es nuevo y se reinició recientemente, incluiré algunos hallazgos. Son bastantes datos, ¡siéntete libre de no estudiarlos!

El estado actual de la máquina es

# 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

Noto que al iniciar sesión, la máquina anuncia
Memory usage: 45%
lo que refleja más de cerca la columna ‘used’ (usado), no la columna ‘free’ (libre).

He estado tomando lecturas periódicas de los siguientes comandos

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

y lo que he visto es que la memoria ‘libre’ se ha intercambiado por memoria ‘buffer’ y ‘cache’, sin que la huella de RAM de los procesos (RSS) aumente. Creo que esto muestra por qué no es bueno rastrear la memoria ‘libre’, incluso si algunos proveedores de alojamiento lo facilitan. Creo que también muestra, en este caso, que no hay una fuga de memoria.

Poco después de reiniciar veo esto:

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

y no mucho despué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

Ves que sidekiq (435 MByte) y unicorns (330-350 cada uno) son los procesos más grandes.

Con el tiempo, la RAM libre y luego el uso de RAM (RSS) de sidekiq disminuyen, presumiblemente debido a que se intercambia, sin efectos indebidos; la máquina no muestra ninguna actividad de paginación. A favor de un mayor espacio de búfer y caché, creo.

# 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

Unas 14 horas después:

# 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

Más tarde…

# 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

Más tarde…

# 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

Más tarde

# 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

Más tarde

# 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

Más tarde

# 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

Gracias por compartir tus observaciones. Veo algo muy similar, excepto que estamos usando una instancia de 2 GB, por lo que hay menos margen. Además, gracias por señalar que algunas medidas de memoria ‘libre’ y ‘usada’ no son necesariamente útiles.

La última vez que reinicié la instancia hace unos días, el uso inicial de memoria fue de 1,23 GB. Desde entonces, ha aumentado gradualmente y ahora está en 1,8 GB. El sitio sigue siendo razonablemente receptivo, por ahora.

El sitio en realidad no tiene muchos usuarios, y no ha habido un aumento reciente en registros de usuarios o actividad. En el último mes ha habido alrededor de 20 temas nuevos, unas 100 publicaciones y unos 4 usuarios activos diarios.

Continuaré monitoreando las cosas y publicaré aquí si la memoria de la instancia se agota nuevamente, o si el sitio se vuelve lento nuevamente, o ambas cosas.

1 me gusta
10

La actualización de Discourse se estaba volviendo una tarea pesada debido a problemas de memoria, así que finalmente actualizamos la máquina virtual de 2 GB a 4 GB. Desde entonces, el uso de memoria se ha estabilizado.

2 Me gusta