O uso de memória aumenta gradualmente após a reinicialização

Instalação
1

Não tenho certeza de quando começou, mas em algum momento nas últimas semanas, presumivelmente após uma atualização do Discourse, o site começou a ficar um pouco lento. Estamos executando a versão 3.4.0.beta2-dev.

Notei que a instância do servidor quase não tinha memória livre, então a reiniciei. Após o Discourse iniciar, o uso de memória estava inicialmente bom (cerca de 1,2 GB), mas começou a aumentar e parece provável que em breve atinja um ponto onde ficará lento novamente.

O site não é particularmente movimentado (20 a 30 visitantes por dia) e tem funcionado bem por muitos anos, até recentemente.

A instância do servidor tem 2 GB de memória, o que deve ser suficiente de acordo com os requisitos que vi (mínimo de 1 GB; recomendado 2 GB).

Parece bastante com um vazamento de memória para mim. Claro, se houver um vazamento, pode não ser o Discourse, mas o Docker ou outra coisa. A instância é usada apenas para o Discourse.

Alguma ideia? Existe uma maneira de verificar se é um vazamento e identificar o processo que está vazando?

2

Memória livre é um conceito muito escorregadio - o único sinal certo de pouca memória é a atividade de paginação.

free
ou
free -h
darão um instantâneo

vmstat 5 5
é muito útil para ver como as coisas estão indo, incluindo a atividade de paginação.

2 curtidas
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

Algum dos itens acima parece problemático? Tenho obtido números de uso de memória do HTOP, que parecem corresponder ao FREE.

Minha principal preocupação é a forma como o uso de memória continua a crescer. Eu esperaria que ele atingisse um certo ponto e depois pairasse por ali, subindo e descendo com o uso do site. A tendência constante de alta é preocupante.

4

certamente, isso parece bom no momento - nenhuma atividade em si e so, que é paginação, e também muito pouco tráfego de disco, que é bi e bo.

o que o linux faz é usar memória livre para cache de disco, então não é ruim ver a memória livre diminuir. A saída do free mostra RAM disponível, a página do manual diz:

available
Estimativa de quanta memória está disponível para iniciar novos aplicativos, sem swapping.

No caso do vmstat, as colunas buff e cache são memória usada para cache de disco e podem crescer para melhorar o desempenho de I/O, mas diminuem quando há pressão de memória. Portanto, tanto para free quanto para vmstat, a quantidade ‘livre’ é uma medida pessimista.

1 curtida
5

Ok, obrigado. Possivelmente a lentidão não estava relacionada ao que parecia ser uma situação de baixa memória. Continuarei a monitorar isso.

1 curtida
6

Ainda é possível que algo esteja aumentando gradualmente.

Esta é uma das minhas táticas para ver o que está acontecendo:

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

Se for fácil monitorar a atividade da CPU e do I/O (disco), eu recomendaria observar esses, em vez do uso de memória. Especialmente o I/O. Se a CPU estiver baixa e o I/O estiver alto, e o fórum estiver lento, isso pode indicar uma escassez impactante de RAM.

8

Alguns motivos, além de um bug, para um site ficar lento: um é o aumento gradual de usuários, atividade do usuário, tamanho do banco de dados; o outro é o Discourse ficando cada vez maior à medida que se desenvolve, adiciona recursos, atualiza componentes de software.

Mas vale a pena ficar de olho na responsividade e se a máquina atual tem o tamanho certo.

(De passagem, noto que a máquina mais barata da Hetzner agora tem 4G de RAM, pelo mesmo preço da máquina mais barata agora indisponível que tem 2G de RAM. Um dos meus sites ainda está rodando no tamanho mais antigo de 2G.)

Para constar, como venho acompanhando o uso do meu site principal, já que ele foi migrado recentemente e o servidor é novo e recém-reiniciado, incluirei algumas descobertas. São muitos dados - sinta-se à vontade para não estudá-los!

O estado atual da máquina é

# 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 ao fazer login a máquina anuncia
Memory usage: 45%
que reflete mais de perto a coluna ‘used’, não a coluna ‘free’.

Tenho tirado leituras periódicas dos seguintes comandos

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

e o que vi é que a memória ‘free’ foi trocada por memória ‘buffer’ e ‘cache’, sem que o footprint de RAM dos processos (RSS) aumentasse. Acho que isso mostra por que não é bom rastrear a memória ‘free’, mesmo que alguns provedores de hospedagem facilitem isso. Acho que também mostra, neste caso, nenhum vazamento de memória.

Pouco depois de reiniciar, vejo isto:

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

e não muito depois

# 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

Você vê que sidekiq (435 MByte) e unicorns (330-350 cada) são os maiores processos.

Com o tempo, a RAM livre e depois o uso de RAM (RSS) do sidekiq diminuem, presumivelmente devido ao page out, sem efeitos indesejados - a máquina não mostra nenhuma atividade de paginação. Em favor de um aumento no espaço de buffer e cache, eu acho.

# 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

Cerca de 14 horas depois:

# 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

Mais 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

Mais 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

Mais 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

Mais 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

Mais 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

Obrigado por compartilhar suas observações. Estou vendo muito o mesmo, exceto que estamos usando uma instância de 2 GB, então há menos margem. Além disso, obrigado por apontar que algumas medidas de memória ‘livre’ e ‘usada’ não são necessariamente úteis.

Quando reiniciei a instância pela última vez, alguns dias atrás, o uso inicial de memória era de 1,23 GB. Desde então, aumentou gradualmente e agora está em 1,8 GB. O site permanece razoavelmente responsivo, por enquanto.

O site na verdade não tem muitos usuários, e não houve aumento recente no registro de usuários ou atividade. No último mês, houve cerca de 20 novos tópicos, cerca de 100 posts e cerca de 4 usuários engajados diariamente.

Continuarei monitorando as coisas e postarei aqui se a memória da instância atingir o máximo novamente, ou se o site ficar lento novamente, ou ambos.

1 curtida
10

Atualizar o Discourse estava se tornando uma tarefa árdua devido a problemas de memória, então finalmente atualizamos a máquina virtual de 2GB para 4GB. Desde então, o uso de memória se estabilizou.

2 curtidas