La instalación de Discourse se ha vuelto cada vez más lenta

Mi instalación de Discourse se ha ido volviendo cada vez más lenta durante las últimas semanas. En el pasado, cuando esto sucedía, reconstruir la aplicación ayudaba. Sin embargo, ahora no parece ayudar.

He buscado consejos en este foro y he probado algunas optimizaciones de la base de datos (vacuum full verbose, rebuild index, vacuum analyze verbose).

Sin embargo, nada de esto parece ayudar, y cuando inicio el contenedor, tarda mucho, mucho tiempo antes de que pueda conectarme al foro.

Si esto continúa, el foro eventualmente se volverá completamente inutilizable. ¿Alguna idea por dónde empezar a buscar?

3 Me gusta

¿Qué tamaño tiene tu base de datos? ¿Cuánta RAM tienes?

1 me gusta

La salida de

vmstat 5 5

podría ser útil aquí. (¡Ejecútalo en un momento en que esté ocurriendo el problema!)

2 Me gusta

Memoria disponible: (de top)

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

Salida de Vmstat: (mientras se intenta cargar cosas, lo cual funciona muy, muy lentamente)

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```

PD: mi sitio está disponible aquí por si ayuda: https://crucible.hubbe.net/

[quote="Jay Pfaffman, post:2, topic:260501, username:pfaffman"]
¿Qué tan grande es tu base de datos?
[/quote]

¿Cómo lo compruebo?
1 me gusta

¿Es Discourse lo único en ese servidor? ¿Cuántos unicornios has configurado en el archivo app.yml?

2 Me gusta

No es lo único, pero es definitivamente lo más importante.

Aquí están los principales procesos por uso de memoria:

  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                                                                         

Casi todo en esta lista, excepto roxen, está relacionado con discourse.

UNICORN_WORKERS está comentado en mi app.yml

Parece que guardar una publicación es particularmente propenso a tiempos de espera y fallos.
No estoy seguro de si eso es una pista de lo que está pasando.

Esa salida de vmstat nos dice que, tal como están las cosas, no hay suficiente RAM.

Podría ser que Discourse esté funcionando como debe, y todo esté como debe estar, pero que tus datos hayan crecido hasta el punto en que 4G de RAM no son suficientes.

O podría ser que algo haya salido mal y se esté utilizando mucha RAM que no debería utilizarse.

Una medida del tamaño es hacer una copia de seguridad sin archivos adjuntos y ver qué tamaño tiene.

Puede que el mini-profiler dé una pista sobre qué acciones de la base de datos están tardando tanto.

Si tienes presupuesto para duplicar la RAM, hazlo. (Si te aseguras de aumentar la RAM pero dejas el almacenamiento como está, si tienes esa opción de tu proveedor, entonces este puede ser un cambio reversible e incluso temporal).

5 Me gusta

Eso es acertado.

Si no puedes permitirte más RAM, puedes intentar establecer valores más bajos para db_shared_buffers (por ejemplo, 128 MB o menos) y limitar UNICORN_WORKERS a solo 2 mientras tanto, ya que necesitas detener el intercambio lo antes posible.

3 Me gusta

62.5 MB

Más RAM es bastante caro con mi proveedor de alojamiento, así que exploraré otras opciones primero. (Y me preocupa que cambiarlo rompa mi precio garantizado…)

Cambié db_shared_buffers a 128Mb y UNICORN_WORKERS a 2.
¿Es launcher app stop / start suficiente para que estas configuraciones surtan efecto?

¿Qué es el mini-profiler y cómo lo uso?

1 me gusta

Con un Alt+P en tu teclado, las acciones posteriores del foro deberían mostrar una cadena de tiempo justo debajo del banner del foro (para mí, a la derecha) y si haces clic en el tiempo, verás una ventana emergente con algunas estadísticas.

Eso es más o menos lo mismo que el mío, funcionando con 1G de RAM. Tengo 2k temas, 15k publicaciones, más de 500 registros.

¿Cuál es la historia de tu Discourse? Recuerdo vagamente un momento en el pasado en el que se suponía que se debía crear un índice para alguna tabla por razones de rendimiento.

¿Qué pasa con los plugins? ¿Puedes ejecutar acciones en modo seguro para ver si se ejecutan más rápido?

2 Me gusta

También podría ser útil pegar tu árbol de procesos completo:

ps auxf

Publiqué el mío aquí
Buscando ayuda para la instalación de discourse

1 me gusta

¿Hay algún lugar fácil para encontrar tales estadísticas?
La mayoría de las estadísticas que veo me muestran lo que sucedió en el último día o semana, pero no totales.

No estoy seguro de a qué te refieres con historia. Pero lo empecé en marzo de 2021.

La primera impresión es que el modo seguro no es más rápido. Jugaré con él y con el mini-profiler para ver si esa impresión se mantiene.

Salida de ps auxf adjunta.
auxf.txt (20.1 KB)

1 me gusta

En la página /about, hay una columna para todo el tiempo.

Parece que tu máquina no se ha reiniciado en más de un año; probablemente valga la pena hacerlo y actualizarla por seguridad al mismo tiempo. Es muy posible que el reinicio ayude.

1 me gusta

Creo que he notado que tu servidor está configurado para usar hypervisor mientras que el mío está configurado para usar lxc. No sé si eso es importante. (Mi sistema muestra un proceso /usr/bin/lxcfs que el tuyo no tiene, y el tuyo muestra un proceso hv_vss_daemon que el mío no tiene.)

Además, tal vez podrías compartir la salida de df -T y swapon.

1.3k temas, 24.7k publicaciones, 631 registros, 7.1k me gusta

Reiniciar máquinas Linux normalmente no ayuda en nada, pero supongo que puedo intentarlo.

¡Estoy de acuerdo con una actitud escéptica al respecto! Pero no lo sugiero a la ligera: estoy bastante seguro de que hemos visto un caso de un sistema de larga duración que mejoró con un reinicio. (Editar: aquí, aunque fue un caso diferente).

Esto es lo que dijo el mini-profiler al guardar una publicación:

Tomó ~30 segundos.