L'uso della memoria aumenta gradualmente dopo il riavvio

Installazione
1

Non sono sicuro di quando sia iniziato, ma a un certo punto nelle ultime settimane, presumibilmente dopo un aggiornamento di Discourse, il sito ha iniziato a sentirsi un po’ lento. Stiamo eseguendo la versione 3.4.0.beta2-dev.

Ho notato che l’istanza del server aveva quasi zero memoria libera, quindi l’ho riavviata. Dopo l’avvio di Discourse, l’utilizzo della memoria era inizialmente buono (circa 1,2 GB), ma ha iniziato ad aumentare e sembra probabile che presto raggiungerà un punto in cui diventerà di nuovo lento.

Il sito non è particolarmente trafficato (da 20 a 30 visitatori al giorno) ed è andato bene per molti anni, fino a poco tempo fa.

L’istanza del server ha 2 GB di memoria, che dovrebbero essere sufficienti secondo i requisiti che ho visto (1 GB minimo; 2 GB consigliati).

Mi sembra piuttosto una perdita di memoria. Naturalmente, se c’è una perdita, potrebbe non essere Discourse, ma Docker o qualcos’altro. L’istanza viene utilizzata solo per Discourse.

Qualche idea? C’è un modo per verificare che si tratti di una perdita e identificare il processo che la causa?

2

La memoria libera è un concetto molto sfuggente: l’unico segno sicuro di memoria insufficiente è l’attività di paging.

free
o
free -h
ti darà uno snapshot

vmstat 5 5
è molto utile per vedere come stanno andando le cose, inclusa l’attività di paging.

2 Mi Piace
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

Qualcosa di quanto sopra sembra problematico? Sto ottenendo i numeri di utilizzo della memoria da HTOP, che sembrano corrispondere a FREE.

La mia preoccupazione principale è il modo in cui l’utilizzo della memoria continua a crescere. Mi aspetterei che raggiunga un certo punto e poi si stabilizzi lì, salendo e scendendo con l’utilizzo del sito. La tendenza costante verso l’alto è preoccupante.

4

Certamente, al momento va bene: nessuna attività in si e so, che è il paging, e anche pochissimo traffico su disco, che è bi e bo.

Linux utilizza la memoria libera per la cache del disco, quindi non è un male vedere la memoria libera diminuire. L’output di free mostra la RAM disponibile, la pagina man dice:

available
Stima di quanta memoria è disponibile per avviare nuove applicazioni, senza swapping.

Nel caso di vmstat, le colonne buff e cache sono memoria utilizzata per la cache del disco e possono aumentare per migliorare le prestazioni di I/O, ma diminuire in caso di pressione sulla memoria. Quindi, sia per free che per vmstat, la quantità ‘free’ è una misura pessimistica.

1 Mi Piace
5

Okay, grazie. Possibilmente la lentezza non era correlata a quella che sembrava una situazione di memoria insufficiente. Continuerò a monitorare la situazione.

1 Mi Piace
6

È ancora possibile che qualcosa stia gradualmente diventando più grande.

Questa è una delle mie tattiche per vedere cosa sta succedendo:

# 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 Mi Piace
7

Se è facile monitorare l’attività della CPU e dell’(I/O) del disco, consiglierei di monitorare quelle, piuttosto che l’uso della memoria. Soprattutto l’I/O. Se la CPU è bassa e l’I/O è alto, e il forum è lento, ciò potrebbe indicare una carenza di RAM di impatto.

8

Un paio di ragioni, oltre a un bug, per cui un sito diventa lento: una è il graduale aumento di utenti, attività degli utenti, dimensioni del database; l’altra è che Discourse diventa sempre più grande man mano che si sviluppa, aggiunge funzionalità, aggiorna componenti software.

Ma vale la pena tenere d’occhio la reattività e se la macchina attuale è dimensionata correttamente.

(Tra parentesi, noto che la macchina più economica di Hetzner ora ha 4G di RAM, allo stesso prezzo della macchina più economica ora non disponibile che ha 2G di RAM. Uno dei miei siti è ancora in esecuzione sulla vecchia dimensione da 2G.)

Ai fini della documentazione, poiché ho monitorato l’utilizzo del mio sito principale, dato che è stato recentemente migrato e il server è nuovo e appena riavviato, includerò alcuni risultati. Sono molti dati, sentiti libero di non studiarli!

Lo stato attuale della macchina è

# 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 che all’accesso la macchina annuncia
Memory usage: 45%
che riflette più da vicino la colonna ‘used’, non la colonna ‘free’.

Ho preso letture periodiche dai seguenti comandi

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

e quello che ho visto è che la memoria ‘free’ è stata scambiata con la memoria ‘buffer’ e ‘cache’, senza che l’impronta di RAM dei processi (RSS) aumentasse. Penso che questo dimostri perché non è bene monitorare la memoria ‘free’, anche se alcuni provider di hosting lo rendono facile. Penso che questo dimostri anche, in questo caso, nessuna perdita di memoria.

Poco dopo il riavvio vedo questo:

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

e non molto tempo dopo

# 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

Vedi che sidekiq (435 MByte) e unicorn (330-350 ciascuno) sono i processi più grandi.

Nel tempo, la RAM libera e poi l’utilizzo della RAM di sidekiq (RSS) diminuiscono, presumibilmente a causa dello swapping, senza effetti indesiderati - la macchina non mostra alcuna attività di paging. A favore di un maggiore spazio di buffer e cache, penso.

# 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

Circa 14 ore dopo:

# 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

Più tardi…

# 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

Più tardi…

# 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

Più tardi

# 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

Più tardi

# 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

Più tardi

# 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

Grazie per aver condiviso le tue osservazioni. Vedo molto lo stesso, tranne per il fatto che stiamo utilizzando un’istanza da 2 GB, quindi c’è meno margine. Inoltre, grazie per aver sottolineato che alcune misurazioni della memoria “libera” e “utilizzata” non sono necessariamente utili.

L’ultima volta che ho riavviato l’istanza qualche giorno fa, l’utilizzo iniziale della memoria era di 1,23 GB. Da allora, è gradualmente aumentato ed è ora a 1,8 GB. Il sito rimane ragionevolmente reattivo, per ora.

Il sito in realtà non ha molti utenti e non c’è stato alcun aumento recente nelle registrazioni o nell’attività degli utenti. Nell’ultimo mese ci sono stati circa 20 nuovi argomenti, circa 100 post e circa 4 utenti attivi giornalieri.

Continuerò a monitorare le cose e posterò qui se la memoria dell’istanza si saturerà di nuovo, o se il sito diventerà di nuovo lento, o entrambi.

1 Mi Piace
10

Aggiornare Discourse stava diventando un compito gravoso a causa di problemi di memoria, quindi abbiamo finalmente aggiornato la macchina virtuale da 2GB a 4GB. Da allora, l’utilizzo della memoria si è stabilizzato.

2 Mi Piace