A instalação do Discourse está ficando cada vez mais lenta

Instalação
1

Minha instalação do Discourse tem ficado cada vez mais lenta nas últimas semanas. No passado, quando isso acontecia, reconstruir o aplicativo ajudava. No entanto, agora não parece ajudar.

Procurei por conselhos neste fórum e tentei algumas otimizações de banco de dados (vacuum full verbose, rebuild index, vacuum analyze verbose).

No entanto, nada disso parece ajudar, e quando inicio o contêiner, leva muito, muito tempo antes que eu possa realmente me conectar ao fórum.

Se isso continuar, o fórum eventualmente se tornará completamente inutilizável. Alguma ideia de onde começar a procurar?

3 curtidas
2

Qual o tamanho do seu banco de dados? Quanta memória RAM você tem?

1 curtida
3

A saída de

vmstat 5 5

poderia ser útil aqui. (Execute no momento em que o problema estiver ocorrendo!)

2 curtidas
4

Memória disponível: (do top)

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

Saída do Vmstat: (enquanto tenta carregar coisas, o que está funcionando muito, muito 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```

PS: meu site está disponível aqui, se ajudar: https://crucible.hubbe.net/

[quote="Jay Pfaffman, post:2, topic:260501, username:pfaffman"]
Qual o tamanho do seu banco de dados?
[/quote]

Como verifico?
1 curtida
5

O Discourse é a única coisa nesse servidor? Quantos unicórnios você configurou no arquivo app.yml?

2 curtidas
6

Não é a única coisa, mas é definitivamente a maior.

Aqui estão os principais processos por uso de memória:

  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
7

Quase tudo nesta lista, exceto roxen, está relacionado ao discourse.

8

UNICORN_WORKERS está comentado em meu app.yml

9

Parece que salvar uma postagem é particularmente propenso a expirar e falhar.
Não tenho certeza se isso é alguma pista sobre o que está acontecendo.

10

A saída do vmstat está nos dizendo que - como as coisas estão - não há RAM suficiente.

Pode ser que o Discourse esteja funcionando como deveria, e tudo esteja como deveria estar, mas que seus dados cresceram a ponto de 4G de RAM não serem suficientes.

Ou pode ser que algo deu errado e muita RAM está em uso, o que não deveria estar em uso.

Uma medida de tamanho é fazer um backup-sem-anexos e ver o quão grande ele é.

Pode ser que o mini-profiler dê uma pista sobre quais ações do banco de dados estão demorando tanto.

Se você tiver orçamento para dobrar a RAM, faça isso. (Se você tomar cuidado para aumentar a RAM, mas deixar o armazenamento como está, se você tiver essa opção do seu provedor, então esta pode ser uma mudança reversível e até mesmo temporária.)

5 curtidas
11

Isso está no ponto.

Se você não pode pagar por mais RAM, pode tentar definir valores mais baixos para db_shared_buffers (digamos 128MB ou menos) e limitar UNICORN_WORKERS a apenas 2 enquanto isso, pois você precisa parar o swapping o mais rápido possível.

3 curtidas
12

62,5 MB

Mais RAM é bastante caro do meu provedor de hospedagem, então explorarei outras opções primeiro. (E estou preocupado que mudá-la quebre meu preço garantido…)

Mudei db_shared_buffers para 128Mb e UNICORN_WORKERS para 2.
O comando launcher app stop / start é suficiente para que essas configurações entrem em vigor?

O que é o mini-profiler e como eu o uso?

1 curtida
13

Com um Alt+P no seu teclado, as ações subsequentes no fórum devem exibir uma string de tempo logo abaixo do banner do fórum (para mim, à direita) e, se você clicar no tempo, verá uma janela pop-up com algumas estatísticas.

Isso é mais ou menos o mesmo que o meu, rodando com 1G de RAM. Tenho 2 mil tópicos, 15 mil posts, mais de 500 cadastros.

Qual é o histórico do seu Discourse? Lembro vagamente de um tempo no passado em que se devia criar um índice para alguma tabela por motivos de desempenho.

E quanto aos plugins? Você pode executar ações em modo de segurança para ver se elas rodam mais rápido?

2 curtidas
14

Também pode ser útil colar sua árvore de processos completa:

ps auxf

Eu postei a minha aqui
Buscando ajuda para instalação do discourse

1 curtida
15

Existe um lugar fácil para encontrar essas estatísticas?
A maioria das estatísticas que vejo me mostra o que aconteceu no último dia ou semana, mas sem totais.

Não tenho certeza do que você quer dizer com histórico. Mas comecei em março de 2021.

A primeira impressão é que o modo de segurança não é mais rápido. Vou brincar com ele e com o mini-profiler para ver se essa impressão se mantém.

Saída de ps auxf anexada.
auxf.txt (20.1 KB)

1 curtida
16

Na página /about, há uma coluna para “all-time”.

Parece que sua máquina não foi reiniciada por mais de um ano - provavelmente vale a pena fazer isso e atualizar por segurança ao mesmo tempo. É bem possível que a reinicialização ajude.

1 curtida
17

Acho que notei que seu servidor está configurado para usar hypervisor, enquanto o meu está configurado para usar lxc. Não sei se isso é importante. (Meu sistema mostra um processo /usr/bin/lxcfs que o seu não mostra, e o seu mostra um processo hv_vss_daemon que o meu não mostra.)

Além disso, talvez você possa compartilhar a saída de df -T e swapon.

18

1,3 mil tópicos, 24,7 mil posts, 631 cadastros, 7,1 mil curtidas

reiniciar máquinas Linux geralmente não ajuda em nada, mas acho que posso tentar.

19

Concordo com uma atitude cética sobre isso! Mas não estou sugerindo isso à toa - tenho certeza de que já vimos um caso de um sistema de longa execução que melhorou com uma reinicialização. (Editar: aqui, embora tenha sido um caso diferente.)

20

É isso que o mini-profiler disse ao salvar uma postagem:

Levou ~30 segundos.