Die Discourse-Installation wird immer langsamer und langsamer und langsamer

Meine Discourse-Installation wird in den letzten Wochen immer langsamer. In der Vergangenheit hat das Neuerstellen der App geholfen, wenn dies geschah. Jetzt scheint es jedoch nicht zu helfen.

Ich habe in diesem Forum nach Ratschlägen gesucht und einige Datenbankoptimierungen ausprobiert (vacuum full verbose, rebuild index, vacuum analyze verbose).

Nichts davon scheint jedoch zu helfen, und wenn ich den Container starte, dauert es sehr, sehr lange, bis ich tatsächlich auf das Forum zugreifen kann.

Wenn dies so weitergeht, wird das Forum schließlich völlig unbrauchbar werden. Irgendwelche Ideen, wo ich anfangen kann zu suchen?

3 „Gefällt mir“

Wie groß ist Ihre Datenbank? Wie viel RAM haben Sie?

1 „Gefällt mir“

Die Ausgabe von

vmstat 5 5

könnte hier hilfreich sein. (Führen Sie dies zu einem Zeitpunkt aus, an dem das Problem auftritt!)

2 „Gefällt mir“

Verfügbarer Arbeitsspeicher: (von top)

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

Vmstat-Ausgabe: (während des Ladens von Dingen, was sehr, sehr langsam funktioniert)

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: Meine Website ist hier verfügbar, falls das hilft: https://crucible.hubbe.net/

[quote="Jay Pfaffman, post:2, topic:260501, username:pfaffman"]
Wie groß ist Ihre Datenbank?
[/quote]

Wie kann ich das überprüfen?
1 „Gefällt mir“

Ist Discourse das Einzige auf diesem Server? Wie viele Unicorns hast du in der app.yml-Datei eingestellt?

2 „Gefällt mir“

Das ist nicht das Einzige, aber definitiv das Größte.

Hier sind die Top-Prozesse nach Speichernutzung:

  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                                                                         

Fast alles auf dieser Liste, außer roxen, bezieht sich auf Discourse.

UNICORN_WORKERS ist in meiner app.yml auskommentiert.

Das Speichern eines Beitrags scheint besonders anfällig für Timeouts und Fehler zu sein.
Ich bin mir nicht sicher, ob das ein Hinweis darauf ist, was vor sich geht.

Die vmstat-Ausgabe sagt uns, dass – wie die Dinge stehen – nicht genügend RAM vorhanden ist.

Es könnte sein, dass Discourse wie vorgesehen funktioniert und alles in Ordnung ist, aber dass Ihre Daten so stark gewachsen sind, dass 4 GB RAM nicht ausreichen.

Oder es könnte sein, dass etwas schief gelaufen ist und viel RAM verwendet wird, der nicht verwendet werden sollte.

Ein Maß für die Größe ist, ein Backup ohne Anhänge zu erstellen und zu sehen, wie groß dieses ist.

Es könnte sein, dass der Mini-Profiler einen Hinweis darauf gibt, welche Datenbankaktionen so lange dauern.

Wenn Sie das Budget haben, den RAM zu verdoppeln, tun Sie das. (Wenn Sie darauf achten, den RAM zu erhöhen, aber den Speicher unverändert lassen, falls Sie eine solche Option von Ihrem Anbieter haben, kann dies eine umkehrbare und sogar eine vorübergehende Änderung sein.)

5 „Gefällt mir“

Das ist auf den Punkt gebracht.

Wenn Sie sich keinen zusätzlichen RAM leisten können, können Sie versuchen, niedrigere Werte für db_shared_buffers (z. B. 128 MB oder weniger) festzulegen und UNICORN_WORKERS vorerst auf nur 2 zu beschränken, da Sie das Swapping so schnell wie möglich stoppen müssen.

3 „Gefällt mir“

62,5 MB

Mehr RAM ist bei meinem Hosting-Anbieter ziemlich teuer, daher werde ich zuerst andere Optionen prüfen. (Und ich mache mir Sorgen, dass eine Änderung meine bestehenden Preise brechen könnte…)

Ich habe db_shared_buffers auf 128 MB und UNICORN_WORKERS auf 2 geändert.
Reicht launcher app stop / start aus, damit diese Einstellungen wirksam werden?

Was ist der Mini-Profiler und wie benutze ich ihn?

1 „Gefällt mir“

Mit Alt+P auf Ihrer Tastatur sollten nachfolgende Forenaktionen eine Zeitangabe direkt unter dem Forenbanner (bei mir rechts) anzeigen, und wenn Sie auf die Zeitangabe klicken, sehen Sie ein Popup-Fenster mit einigen Statistiken.

Das ist ungefähr das Gleiche wie bei mir, wenn ich mit 1 GB RAM arbeite. Ich habe 2.000 Themen, 15.000 Beiträge, 500+ Anmeldungen.

Wie ist die Geschichte Ihres Discourse? Ich erinnere mich dunkel an eine Zeit in der Vergangenheit, als man aus Leistungsgründen einen Index für eine Tabelle erstellen sollte.

Was ist mit Plugins? Können Sie Aktionen im sicheren Modus ausführen, um zu sehen, ob sie schneller laufen?

2 „Gefällt mir“

Es könnte auch nützlich sein, Ihren vollständigen Prozessbaum einzufügen:

ps auxf

Ich habe meinen hier gepostet
Hilfe bei der Discourse-Installation gesucht

1 „Gefällt mir“

Gibt es eine einfache Möglichkeit, solche Statistiken zu finden?
Die meisten Statistiken, die ich sehe, zeigen mir, was am letzten Tag oder in der letzten Woche passiert ist, aber keine Gesamtsummen.

Ich bin mir nicht sicher, was du mit Geschichte meinst. Aber ich habe im März 2021 damit angefangen.

Erster Eindruck ist, dass der Safe Mode nicht schneller ist. Ich werde damit und dem Mini-Profiler herumspielen, um zu sehen, ob dieser Eindruck bestehen bleibt.

Ausgabe von ps auxf angehängt.
auxf.txt (20,1 KB)

1 „Gefällt mir“

Auf der /about-Seite gibt es eine Spalte für „all-time“.

Es sieht so aus, als ob Ihr Computer seit über einem Jahr nicht mehr neu gestartet wurde – wahrscheinlich lohnt es sich, dies zu tun und gleichzeitig die Sicherheit zu aktualisieren. Es ist durchaus möglich, dass der Neustart hilft.

1 „Gefällt mir“

Ich glaube, mir ist aufgefallen, dass Ihr Server für die Verwendung von Hypervisoren eingerichtet ist, während meiner für LXC eingerichtet ist. Ich weiß nicht, ob das wichtig ist. (Mein System zeigt einen Prozess /usr/bin/lxcfs an, den Ihres nicht hat, und Ihres zeigt einen Prozess hv_vss_daemon an, den meines nicht hat.)

Außerdem könnten Sie vielleicht die Ausgabe von df -T und swapon teilen.

1,3 T. Themen, 24,7 T. Beiträge, 631 Anmeldungen, 7,1 T. Likes

Das Neustarten von Linux-Maschinen hilft normalerweise nichts, aber ich schätze, ich kann es versuchen.

Ich stimme einer skeptischen Haltung dazu zu! Aber ich schlage es nicht leichtfertig vor – ich bin ziemlich sicher, dass wir einen Fall eines langlaufenden Systems gesehen haben, das sich mit einem Neustart verbessert hat. (Bearbeiten: hier, obwohl es ein anderer Fall war.)

Das hat der Mini-Profiler beim Speichern eines Beitrags gesagt:

Es hat ~30 Sekunden gedauert.