L'installazione di Discourse è diventata sempre più lenta

La mia installazione di Discourse è diventata sempre più lenta nelle ultime settimane. In passato, quando ciò accadeva, la ricostruzione dell’app aiutava. Tuttavia, ora non sembra più aiutare.

Ho cercato consigli su questo forum e ho provato alcune ottimizzazioni del database (vacuum full verbose, rebuild index, vacuum analyze verbose).

Tuttavia, nessuna di queste sembra aiutare e quando avvio il container, ci vuole molto, molto tempo prima che io possa effettivamente connettermi al forum.

Se la situazione continua così, il forum diventerà alla fine completamente inutilizzabile. Avete qualche idea da dove iniziare a cercare?

3 Mi Piace

Quanto è grande il tuo database? Quanta RAM hai?

1 Mi Piace

L’output di

vmstat 5 5

potrebbe essere utile qui. (Eseguilo in un momento in cui si sta verificando il problema!)

2 Mi Piace

Memoria disponibile: (da top)

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

Output di Vmstat: (mentre si cerca di caricare le cose, cosa che sta andando molto, molto 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: il mio sito è disponibile qui, se può aiutare: https://crucible.hubbe.net/

[quote="Jay Pfaffman, post:2, topic:260501, username:pfaffman"]
Quanto è grande il tuo database?
[/quote]

Come faccio a controllare?
1 Mi Piace

È Discourse l’unica cosa su quel server? Quanti unicorn hai impostato nel file app.yml?

2 Mi Piace

Non è l’unica cosa, ma è sicuramente la più importante.

Ecco i processi principali per utilizzo di memoria:

  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                                                                         

Quasi tutto in questo elenco, eccetto roxen, è correlato al discorso.

UNICORN_WORKERS è commentato nel mio app.yml

Sembra che il salvataggio di un post sia particolarmente soggetto a timeout e fallimenti.
Non sono sicuro che questo possa essere un indizio su cosa stia succedendo.

L’output di vmstat ci dice che, così come stanno le cose, non c’è abbastanza RAM.

Potrebbe essere che Discourse stia funzionando come dovrebbe, e tutto sia a posto, ma che i tuoi dati siano cresciuti al punto che 4G di RAM non sono sufficienti.

Oppure potrebbe essere che qualcosa sia andato storto e molta RAM sia in uso quando non dovrebbe esserlo.

Una misura delle dimensioni è fare un backup senza allegati e vedere quanto è grande.

Potrebbe essere che il mini-profiler dia un indizio su quali azioni del database stiano richiedendo così tanto tempo.

Se hai il budget per raddoppiare la RAM, fallo. (Se ti prendi cura di aumentare la RAM ma lasci invariato lo storage, se hai tale opzione dal tuo provider, allora questa può essere una modifica reversibile e persino temporanea.)

5 Mi Piace

Questo è il punto.

Se non puoi permetterti più RAM, puoi provare a impostare valori inferiori per db_shared_buffers (diciamo 128 MB o meno) e limitare UNICORN_WORKERS a soli 2 nel frattempo, poiché devi interrompere lo swapping il prima possibile.

3 Mi Piace

62,5 MB

Più RAM è piuttosto costosa dal mio provider di hosting, quindi esplorerò prima altre opzioni. (E sono preoccupato che cambiarla possa compromettere il mio prezzo grandfathered…)

Ho cambiato db_shared_buffers in 128Mb e UNICORN_WORKERS in 2.
È sufficiente launcher app stop / start per rendere effettive queste impostazioni?

Cos’è il mini-profiler e come lo uso?

1 Mi Piace

Con Alt+P sulla tastiera, le azioni successive del forum dovrebbero mostrare una stringa di temporizzazione appena sotto il banner del forum (per me, sulla destra) e se si fa clic sulla temporizzazione, si aprirà una finestra popup con alcune statistiche.

È più o meno lo stesso del mio, in esecuzione con 1 GB di RAM. Ho 2k argomenti, 15k post, 500+ iscrizioni.

Qual è la storia del tuo Discourse? Ricordo vagamente un tempo in passato in cui si doveva creare un indice per una tabella per motivi di prestazioni.

E i plugin? Puoi eseguire azioni in modalità provvisoria per vedere se vengono eseguite più velocemente?

2 Mi Piace

Potrebbe anche essere utile incollare il tuo intero albero di processi:

ps auxf

Ho pubblicato il mio qui
Richiesta di aiuto per l’installazione di discourse

1 Mi Piace

C’è un posto facile dove trovare queste statistiche?
La maggior parte delle statistiche che vedo mi mostrano cosa è successo nell’ultimo giorno o settimana, ma nessun totale.

Non sono sicuro di cosa intendi per cronologia. Ma l’ho iniziato nel marzo 2021.

La prima impressione è che la modalità sicura non sia più veloce. Ci giocherò e userò il mini-profiler per vedere se questa impressione regge.

Output di ps auxf allegato.
auxf.txt (20,1 KB)

1 Mi Piace

Nella pagina /about, c’è una colonna per il totale.

Sembra che la tua macchina non sia stata riavviata per ben oltre un anno - probabilmente vale la pena farlo, e aggiornare per la sicurezza allo stesso tempo. È solo possibile che il riavvio aiuti.

1 Mi Piace

Penso di aver notato che il tuo server è configurato per utilizzare l’hypervisor mentre il mio è configurato per utilizzare lxc. Non so se sia importante. (Il mio sistema mostra un processo /usr/bin/lxcfs che il tuo non ha, e il tuo mostra un processo hv_vss_daemon che il mio non ha.)

Inoltre, forse potresti condividere l’output di df -T e swapon.

1,3 mila argomenti, 24,7 mila post, 631 iscrizioni, 7,1 mila like

riavviare le macchine Linux di solito non aiuta in nulla, ma suppongo di poterci provare.

Sono d’accordo con un atteggiamento scettico su questo! Ma non lo suggerisco alla leggera: sono abbastanza sicuro di aver visto un caso di un sistema in esecuzione da molto tempo che è migliorato con un riavvio. (Modifica: qui, anche se era un caso diverso.)

Questo è ciò che il mini-profiler ha detto per il salvataggio di un post:

Ci sono voluti circa 30 secondi.