Speichernutzung steigt nach dem Neustart allmählich an

Installation
1

Ich bin mir nicht sicher, wann es angefangen hat, aber irgendwann in den letzten Wochen, vermutlich nach einem Discourse-Update, begann die Seite etwas träge zu werden. Wir verwenden 3.4.0.beta2-dev.

Mir fiel auf, dass die Serverinstanz fast keinen freien Speicher mehr hatte, also habe ich sie neu gestartet. Nachdem Discourse gestartet war, war die Speichernutzung anfangs in Ordnung (etwa 1,2 GB), aber sie begann langsam anzusteigen und wird wahrscheinlich bald wieder einen Punkt erreichen, an dem sie träge wird.

Die Seite ist nicht besonders stark besucht (20 bis 30 Besucher täglich) und war viele Jahre lang in Ordnung, bis vor kurzem.

Die Serverinstanz hat 2 GB Speicher, was laut den von mir gesehenen Anforderungen (1 GB Minimum; 2 GB empfohlen) ausreichen sollte.

Es fühlt sich für mich eher wie ein Speicherleck an. Natürlich, wenn es ein Leck gibt, ist es vielleicht nicht Discourse, sondern Docker oder etwas anderes. Die Instanz wird nur für Discourse verwendet.

Irgendwelche Ideen? Gibt es eine Möglichkeit zu überprüfen, ob es sich um ein Leck handelt und den leckenden Prozess zu identifizieren?

2

Freier Speicher ist ein sehr schwer fassbares Konzept – das einzige sichere Zeichen für zu wenig Speicher ist Paging-Aktivität.

free
oder
free -h
liefert Ihnen eine Momentaufnahme

vmstat 5 5
ist sehr nützlich, um zu sehen, wie die Dinge laufen, einschließlich Paging-Aktivität.

2 „Gefällt mir“
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

Scheint etwas davon problematisch zu sein? Ich erhalte die Zahlen zur Speichernutzung von HTOP, die mit FREE übereinstimmen.

Meine Hauptsorge ist die Art und Weise, wie die Speichernutzung weiter wächst. Ich würde erwarten, dass sie einen bestimmten Punkt erreicht und dann dort schwankt, je nach Nutzung der Website auf und ab geht. Der stetige Aufwärtstrend ist beunruhigend.

4

sicher, das sieht im Moment gut aus – keine Aktivität in si und so, was Paging ist, und auch sehr wenig Festplattenverkehr, was bi und bo ist.

Linux verwendet freien Speicher für das Festplatten-Caching, daher ist es nicht schlecht, wenn der freie Speicher niedrig ist. Die Ausgabe von free zeigt den verfügbaren RAM an, die Manpage besagt:

verfügbar
Schätzung, wie viel Speicher für den Start neuer Anwendungen ohne Swapping verfügbar ist.

Im Fall von vmstat sind die Spalten buff und cache Speicher, der für das Festplatten-Caching verwendet wird und wachsen kann, um die I/O-Leistung zu verbessern, aber schrumpft, wenn Speicherdruck herrscht. Daher ist der Betrag ‘free’ für sowohl free als auch vmstat ein pessimistisches Maß.

1 „Gefällt mir“
5

Okay, danke. Möglicherweise hing die Trägheit nicht mit einer scheinbar geringen Speichersituation zusammen. Ich werde dies weiter beobachten.

1 „Gefällt mir“
6

Es ist immer noch möglich, dass etwas allmählich größer wird.

Dies ist eine meiner Taktiken, um zu sehen, was vor sich geht:

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

(oder ps auxc)

2 „Gefällt mir“
7

Wenn es einfach ist, die CPU- und (Festplatten-)E/A-Aktivität zu überwachen, würde ich empfehlen, diese zu beobachten und nicht den Speicherverbrauch. Insbesondere die E/A. Wenn die CPU niedrig und die E/A hoch ist und das Forum langsam ist, könnte dies auf einen spürbaren RAM-Mangel hindeuten.

8

Ein paar Gründe, abgesehen von einem Fehler, warum eine Website träge wird: Einer ist die allmähliche Zunahme von Benutzern, Benutzeraktivität und Datenbankgröße; der andere ist, dass Discourse mit der Entwicklung, dem Hinzufügen von Funktionen und dem Aktualisieren von Softwarekomponenten immer größer wird.

Es lohnt sich jedoch, die Reaktionsfähigkeit im Auge zu behalten und zu prüfen, ob die aktuelle Maschine richtig dimensioniert ist.

(Nebenbei bemerke ich, dass die günstigste Maschine von Hetzner jetzt 4 GB RAM hat, zum gleichen Preis wie die nicht mehr verfügbare günstigste Maschine mit 2 GB RAM. Eine meiner Websites läuft immer noch auf der älteren 2-GB-Größe.)

Zur Dokumentation, da ich die Nutzung meiner Hauptwebsite verfolge und der Server neu und frisch neu gestartet ist, werde ich einige Ergebnisse einbeziehen. Es sind ziemlich viele Daten – studieren Sie sie ruhig nicht!

Der aktuelle Zustand der Maschine ist

# 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

Ich bemerke, dass die Maschine beim Anmelden ankündigt:
Memory usage: 45%
was am ehesten der Spalte ‘used’ entspricht, nicht der Spalte ‘free’.

Ich habe periodische Messungen mit den folgenden Befehlen durchgeführt:

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

und was ich gesehen habe, ist, dass der freie Speicher gegen ‘buffer’- und ‘cache’-Speicher getauscht wurde, ohne dass der RAM-Fußabdruck (RSS) der Prozesse zugenommen hat. Ich denke, das zeigt, warum es nicht gut ist, den freien Speicher zu verfolgen, auch wenn es einige Hosting-Anbieter leicht machen. Ich denke, das zeigt auch in diesem Fall keinen Speicherleck.

Kurz nach dem Neustart sehe ich Folgendes:

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

und nicht lange danach

# 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

Sie sehen, dass Sidekiq (435 MByte) und Unicorns (jeweils 330-350) die größten Prozesse sind.

Im Laufe der Zeit nehmen der freie RAM und dann die Sidekiq-RAM-Auslastung (RSS) ab, vermutlich aufgrund von Paging, ohne übermäßige Auswirkungen – die Maschine zeigt keine Paging-Aktivität. Ich denke, zugunsten von erhöhtem Puffer- und Cache-Speicher.

# 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

Etwa 14 Stunden später:

# 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

Später…

# 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

Später…

# 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

Später

# 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

Später

# 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

Später

# 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

Danke für das Teilen Ihrer Beobachtungen. Ich sehe weitgehend dasselbe, außer dass wir eine 2-GB-Instanz verwenden, sodass weniger Spielraum vorhanden ist. Danke auch für den Hinweis, dass einige Messungen von „freiem“ und „belegtem“ Arbeitsspeicher nicht unbedingt hilfreich sind.

Als ich die Instanz vor ein paar Tagen das letzte Mal neu gestartet habe, betrug die anfängliche Speichernutzung 1,23 GB. Seitdem ist sie allmählich angestiegen und liegt jetzt bei 1,8 GB. Die Website bleibt vorerst einigermaßen reaktionsschnell.

Die Website hat eigentlich nicht viele Benutzer, und es gab keine jüngste Zunahme von Benutzerregistrierungen oder Aktivitäten. Im letzten Monat gab es etwa 20 neue Themen, etwa 100 Beiträge und etwa 4 täglich aktive Benutzer.

Ich werde die Dinge weiter beobachten und hier posten, wenn entweder der Speicher der Instanz wieder voll ist oder die Website wieder träge wird, oder beides.

1 „Gefällt mir“
10

Das Upgrade von Discourse wurde aufgrund von Speicherproblemen zu einer mühsamen Aufgabe, daher haben wir die virtuelle Maschine endlich von 2 GB auf 4 GB aufgerüstet. Seitdem hat sich die Speichernutzung stabilisiert.

2 „Gefällt mir“