Utilizzo elevato di CPU e disco dopo il ripristino da un aggiornamento fallito

Installazione
1

Dopo aver scoperto il rilascio di 3.3.0-beta1, ho immediatamente aggiornato la mia istanza Discourse dall’interfaccia web.

Tuttavia, durante il processo di aggiornamento, i log dell’interfaccia web si sono bloccati per più di quindici minuti senza ulteriori output (ricordo che l’ultimo output fosse una serie di ellissi crescenti? Potrebbe essere stato così, sono un po’ incerto). Circa 2 ore dopo, ho controllato lo stato del server dalla piattaforma cloud e ho sospettato che si fosse bloccato, quindi ho eseguito un riavvio soft dalla piattaforma cloud.

Dopo il riavvio, ho prontamente eseguito un backup di Discourse dalla riga di comando, scaricato localmente il backup e app.yml, e poi ho reinstallato completamente Discourse (ovviamente, l’ultima versione). Successivamente, ho caricato il backup e avviato il processo di ripristino dalla riga di comando.

Il ripristino è andato a buon fine, ma ora il mio Discourse sta riscontrando gravi problemi di prestazioni. In precedenza, l’utilizzo della CPU durante l’uso normale non superava il 10%, ma ora raggiunge picchi intorno al 30% anche durante le ore non di punta, e anche le letture del disco sono relativamente elevate. Peggio ancora, a volte il server si blocca inspiegabilmente, con letture del disco che raggiungono circa 1900 al secondo (questo è il limite del mio server cloud), e la CPU è oltre il 40% in stato di attesa. Le pagine web non riescono a caricarsi, mostrando timeout di connessione. Al momento, sto eseguendo vmstat e top, ma sfortunatamente non ho conservato l’output. Ricordo che lo swap IO era quasi zero, indicando puramente letture del disco. Il numero di thread bloccati superava i 100.

Sospetto che questo aggiornamento fallito possa aver causato alcuni danni, possibilmente ai dati all’interno del backup, piuttosto che al software stesso. C’è un modo per—uh, non sono sicuro?—aggiornare o eliminare qualche cache o operazioni simili? O forse… eseguire nuovamente l’aggiornamento? (Dopotutto, gli aggiornamenti di Discourse sono piuttosto frequenti e possono essere aggiornati quasi in qualsiasi momento.)

Come soluzione temporanea, ho installato un watchdog software per riavviare automaticamente durante i carichi elevati. Tuttavia, questa non è in definitiva una soluzione a lungo termine, e non ho trovato problemi simili qui; evidentemente, non è un problema con il software Discourse stesso. Mi chiedo come affrontare questo problema.

Se hai bisogno che esegua alcuni comandi sul server per verificarne lo stato durante i carichi elevati, non esitare a chiedere. Farò del mio meglio per mantenere la mia connessione SSH e ottenere questi dati senza riavviare.

2

Com’è la tua coda sidekiq? Potrebbe semplicemente rifare tutti i post e il carico si calmerà alla fine una volta che il backlog sarà stato smaltito. Cioè, la situazione dovrebbe essere transitoria.

Questo mi è successo alcune volte di recente. Ogni volta ho riavviato manualmente e poi eseguito una ricostruzione da riga di comando. Ovviamente non è una buona soluzione a lungo termine e rischiosa.

Questo è un segno che la tua macchina non ha più abbastanza memoria. Considera di aumentare lo swap per far fronte ai picchi.

Sto scoprendo di aver bisogno di una macchina da 4 GB più 3 GB di swap ora per eseguire gli aggiornamenti online: quanta memoria hai?

3

In realtà, non stava riscontrando carichi estremamente elevati subito dopo il ripristino, il che suppongo sia normale. Ma nel mio caso, dopo che il carico era sceso a circa il 2% a seguito del ripristino, mentre stavo apportando alcune modifiche all’interfaccia web, improvvisamente la pagina ha smesso di caricarsi dopo un’azione. Controllando la piattaforma del server cloud, CPU e letture del disco erano molto elevate. Non credo che questo sia un problema di ribaking di tutti i post.

Dato che il mio server è attualmente in uno stato normale, ecco l’interfaccia Sidekiq:

image
image1366×607 68.5 KB

image
image1229×314 48 KB

4

Ho 2 GB di memoria fisica e 2 GB di swap. Sembra che lo swap sia stato abilitato automaticamente durante il processo di installazione di Discourse? Comunque, non l’ho configurato manualmente.

Ho aggiunto manualmente lo swap fino a un totale di 6 GB ora.

5

Ok, questo è il tuo problema.

Dalla mia recente esperienza, sembra che il processo di compilazione web sia molto più esigente e potresti sperimentare con uno swap molto più grande o migrare su un server più grande.

6

Comunque, nei miei precedenti tentativi di eseguire backup tramite l’interfaccia web, i log a volte si bloccavano. Ora, eseguo tutti i backup e i ripristini dalla riga di comando (ad eccezione dei backup automatici, che non sono mai falliti e funzionano bene). Mi chiedo se si tratti di un problema comune? Esiste un comando per eseguire l’aggiornamento? Dovrei continuare a eseguire gli aggiornamenti tramite la riga di comando in futuro? Ciò potrebbe potenzialmente aumentare il tasso di successo?

7

Nell’uso quotidiano, noto anche un aumento significativo dei ritardi nel caricamento delle pagine web rispetto a prima, ed è molto probabile che non si tratti di un problema di rete, ma di un problema di prestazioni. Ecco i dati sulle prestazioni durante il caricamento della homepage:

image
image702×318 10.8 KB

8

The server freezed again. (watchdog is stopped manually to get full log without reboot) Here’s the top and vmstat output:

Note that the top output here hasn’t updated much since the server freeze, unlike vmstat, so it may not reflect the latest data.

top - 21:53:16 up  2:19,  3 users,  load average: 19.20, 4.89, 1.90
Tasks: 164 total,   1 running, 163 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.7 us,  7.2 sy,  0.0 ni,  0.0 id, 91.8 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :   1668.6 total,     75.9 free,   1473.1 used,    119.6 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.     36.8 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                   
     92 root      20   0       0      0      0 S   2.8   0.0   0:08.01 kswapd0                                                                   
   2504 root      10 -10  123496   6932      0 D   1.6   0.4   2:59.44 AliYunDunMonito                                                           
     90 root       0 -20       0      0      0 I   1.0   0.0   0:01.10 kworker/1:1H-kblockd                                                      
   1320 root      20   0 1236124   2116      0 S   0.8   0.1   0:00.96 containerd-shim                                                           
   2493 root      10 -10   87652   1744      0 S   0.6   0.1   0:44.69 AliYunDun                                                                 
   1008 root      20   0 1276372   2160      0 S   0.5   0.1   0:43.62 argusagent                                                                
    725 root      20   0  689584   3860      0 S   0.3   0.2   0:08.16 aliyun-service                                                            
   1964 message+  20   0   74800  12512      0 D   0.3   0.7   0:19.97 redis-server                                                              
   1973 www-data  20   0   56840   4872    472 D   0.3   0.3   0:01.36 nginx                                                                     
   2081 admin     20   0  519788 263284      4 S   0.3  15.4   0:07.88 ruby                                                                      
   2214 admin     25   5 5338856 495356      0 S   0.3  29.0   0:31.95 ruby                                                                      
   2227 admin     20   0 5246956 484488      4 S   0.3  28.4   0:33.31 ruby                                                                      
   2467 systemd+  20   0  215196  15052  11348 D   0.3   0.9   0:00.45 postmaster                                                                
    785 root      20   0   42256    748      0 S   0.2   0.0   0:07.58 AliYunDunUpdate                                                           
    805 root      20   0 1798676  11832      0 S   0.2   0.7   0:02.24 containerd                                                                
   1027 root      20   0 2281464  29296      0 S   0.2   1.7   0:01.96 dockerd                                                                   
   2056 systemd+  20   0   67872   2192      0 D   0.2   0.1   0:00.39 postmaster                                                                
   2243 root      20   0   17204   5068   2592 S   0.2   0.3   0:00.34 sshd                                                                      
   2555 root      20   0   10496   2736   1916 R   0.2   0.2   0:11.41 top                                                                       
   9998 admin     20   0 5057740 313028      4 S   0.2  18.3   0:04.83 ruby                                                                      
  11658 admin     20   0   10944    252      0 D   0.2   0.0   0:00.09 sleep                                                                     
      1 root      20   0  166776   6568   2808 D   0.1   0.4   0:01.42 systemd                                                                   
     22 root      20   0       0      0      0 S   0.1   0.0   0:00.31 ksoftirqd/1                                                               
    149 root       0 -20       0      0      0 I   0.1   0.0   0:00.17 kworker/0:1H-kblockd                                                      
    707 systemd+  20   0   16260   2296   1212 D   0.1   0.1   0:00.16 systemd-network                                                           
    723 root      20   0   19424    984      0 S   0.1   0.1   0:01.58 assist_daemon                                                             
   1965 root      20   0    6680    280      0 D   0.1   0.0   0:00.05 cron                                                                      
   1974 www-data  20   0   55912   3996    472 D   0.1   0.2   0:00.98 nginx                                                                     
   2054 systemd+  20   0  213244   6344   4384 S   0.1   0.4   0:02.02 postmaster                                                                
   2055 systemd+  20   0  213780   3208    924 D   0.1   0.2   0:00.12 postmaster                                                                
   2270 root      20   0   17204   3880   1404 D   0.1   0.2   0:00.67 sshd            

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0  71456    624 134980    0    0 11302     4 2209 3766  1  1 96  2  0
 0  1      0  72756   1452 132412    0    0 15250    12 2418 3969  1  2 94  4  0
 0  0      0  67724   1244 137444    0    0  4485     2 2083 3700  1  1 98  1  0
 0  0      0  80388    928 124660    0    0 26388    10 2650 4018  1  2 92  4  0
 0  0      0  78256    696 126228    0    0 14752     6 2286 3792  1  1 95  3  0
 0  0      0  72252   1680 130784    0    0 40334    41 2938 4212  1  2 89  7  0
 0  0      0  74812    712 128588    0    0 15904    34 2309 3839  1  1 95  3  0
 2  0      0  71120    856 132224    0    0 54282     5 3292 4382  1  3 85 10  0
 0  0      0  73668    600 128232    0    0 30135    35 2795 4212  1  2 92  5  0
 0  0      0  65160   1524 135636    0    0 30239     6 2842 4247  1  2 90  7  0
 0  0      0  74480   1416 126484    0    0 11761     8 2254 3793  1  2 95  2  0
 1  0      0  80096   1188 120752    0    0 37110     2 2907 4163  1  4 88  7  0
 0  0      0  77880    688 122928    0    0  8439     5 2151 3719  1  1 97  2  0
 0  8      0  76744   1256 122536    0    0 110986    14 4410 4860  1  6 34 59  0
 0 13      0  71776    244 128496    0    0 126111    21 4386 4699  1  7  0 91  0
 1 30      0  71860    356 127916    0    0 125040    21 4634 7331  1  7  0 91  0
 3 31      0  77448    204 122688    0    0 125980    10 4167 8370  1  5  0 94  0
 3 44      0  68184    168 132192    0    0 150011     0 4296 9015  0  7  0 93  0
 1 44      0  74812    216 124700    0    0 204040     0 4949 10108  1  6  0 93  0
 6 35      0  66588    244 133160    0    0 131782     2 6238 12786  1  7  0 93  0
 1 39      0  68156    556 130996    0    0 144440    11 4608 9622  1  8  0 92  0
 0 71      0  72256    212 126520    0    0 169879    12 4780 10242  1 10  0 89  0
 0 91      0  66752    112 132476    0    0 542955    18 7422 17564  0 52  0 48  0
 6 89      0  70324    172 129516    0    0 404754    21 6033 14379  0 52  0 48  0
 3 87      0  60468    156 138060    0    0 499604     1 10640 26065  0 56  0 44  0
 5 91      0  63456    152 135588    0    0 725747    11 10827 25806  0 55  0 45  0
 4 101      0  69596    168 129132    0    0 558872     8 7755 18745  0 56  0 44  0
 6 93      0  66516    156 132772    0    0 394003     3 12549 30622  0 54  0 46  0
 4 94      0  62872    152 135976    0    0 656057     0 7790 18800  0 52  0 48  0
 2 95      0  57072    156 141552    0    0 347776     0 10390 25943  0 56  0 44  0
 4 97      0  66308    164 132964    0    0 641920     0 9963 24307  0 55  0 45  0
13 90      0  75620    152 123836    0    0 658883     0 7870 19260  0 55  0 45  0
 2 96      0  66244    152 131496    0    0 764233     0 16078 40498  0 55  0 45  0
 1 102      0  60156    224 137440    0    0 542241     0 10243 24560  0 54  0 46  0
13 90      0  62488    164 135548    0    0 671301     0 13771 34230  0 55  0 45  0
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3 101      0  61812    100 136048    0    0 548615     0 10328 26305  0 55  0 45  0
 2 102      0  61412     92 135928    0    0 1003845     0 17283 42751  0 56  0 44  0
 8 98      0  60408    152 136896    0    0 662925     0 11369 29130  0 55  0 45  0
 2 104      0  68292    152 129552    0    0 628286     0 13772 34122  0 56  0 44  0
 2 99      0  65352    152 132436    0    0 494863     5 8766 21559  0 54  0 46  0
10 94      0  58344     96 138800    0    0 669390     0 9294 22968  0 56  0 44  0
 3 95      0  61180    100 135444    0    0 598622     0 13342 32430  0 57  0 43  0
 8 96      0  59444    160 137584    0    0 720255     0 10812 25735  0 57  0 43  0
14 89      0  66844    160 130072    0    0 665390     0 17496 43187  0 56  0 44  0
 1 98      0  64668    152 132756    0    0 498328     0 7262 18622  0 55  0 45  0
 1 98      0  61848    172 135060    0    0 438272     0 7693 19947  0 56  0 44  0
 3 102      0  60636    152 136548    0    0 1020531     0 17162 43981  0 55  0 45  0
 2 93      0  55096    164 141908    0    0 595678     0 14379 37088  0 55  0 45  0
 9 100      0  61704    152 134692    0    0 368380     0 10621 27539  0 55  0 45  0
 2 104      0  63784    148 132620    0    0 767905     8 11090 28866  0 56  0 44  0
 2 110      0  60124    232 135636    0    0 882479     0 14778 38194  0 55  0 45  0
 3 109      0  64632    156 131448    0    0 489138     0 11521 30264  0 56  0 44  0
 2 107      0  65852     36 130592    0    0 1214409     0 17572 45932  0 55  0 45  0
 2 97      0  60260     96 135668    0    0 559811     0 14592 37198  0 56  0 44  0
 1 103      0  56064    104 139668    0    0 514522     0 11059 26834  0 57  0 43  0
 7 97      0  62624    160 133492    0    0 646888     4 7819 19552  0 57  0 43  0
 8 102      0  65404    152 130172    0    0 526268     0 11623 29396  0 56  0 44  0

I’ll keep the freezing state without rebooting. If you need me to execute some commands on the server to check its status during high loads, feel free to ask. I’ll do my best to maintain my SSH connection and obtain all data without rebooting.

other data from cloud server platform:

image
image1137×369 38.7 KB

image
image758×358 24.5 KB

9

Questo sembra sospetto, potrebbe essere o meno la causa. Qualcosa sta (probabilmente) effettuando un’enorme quantità di letture su disco. AliYunDun sembra essere lo strumento del provider cloud. AliYunDunMonitor è (possibilmente) bloccato in attesa su disco, è in esecuzione con priorità elevata, ha accumulato molto tempo di CPU.

Ho visto che qualcuno da qualche parte ha scritto uno script per terminare tali processi. Il tono è arrabbiato. (Non posso dire se quello script sia sicuro o una buona idea.)

Ma è anche possibile che un processo di Discourse stia effettuando tutte le letture su disco.

Forse prova

apt-get install iotop
iotop -b -d 15 -P -o

e guardalo finché non si blocca.

10

Ok, ecco l’output di iotop quando si blocca:

Total DISK READ:         7.92 M/s | Total DISK WRITE:        11.70 K/s
Current DISK READ:      12.14 M/s | Current DISK WRITE:      17.29 K/s
    PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
      1 be/4 root        6.12 K/s    0.00 B/s  ?unavailable?  init noibrs
    300 be/3 root        0.00 B/s    2.93 K/s  ?unavailable?  [jbd2/vda3-8]
    374 be/3 root       10.64 K/s    0.00 B/s  ?unavailable?  systemd-journald
    709 be/4 systemd-    3.99 K/s    0.00 B/s  ?unavailable?  systemd-resolved
    723 be/4 root       51.07 K/s    0.00 B/s  ?unavailable?  assist_daemon
    725 be/4 root      856.83 K/s  272.40 B/s  ?unavailable?  aliyun-service
    770 be/4 root       63.31 K/s    0.00 B/s  ?unavailable?  python3 -Es /usr/sbin/tuned -l -P
    785 be/4 root       12.77 K/s    0.00 B/s  ?unavailable?  AliYunDunUpdate
    805 be/4 root      389.98 K/s    0.00 B/s  ?unavailable?  containerd
   1008 be/4 root      242.60 K/s  544.80 B/s  ?unavailable?  argusagent
   1027 be/4 root      690.31 K/s    0.00 B/s  ?unavailable?  dockerd -H fd:// --containerd=/run/containerd/containerd.sock
   1320 be/4 root      241.01 K/s    0.00 B/s  ?unavailable?  containerd-shim-runc-v2 -namespace moby -id 6e9880833995c5e2a295ed6571129387036824d304e09f43d5e1333ebd7fdbd5 -address /run/containerd/containerd.sock
   1953 be/4 root     1906.79 B/s    0.00 B/s  ?unavailable?  runsvdir -P /etc/service
   1962 be/4 admin      85.12 K/s    0.00 B/s  ?unavailable?  bash config/unicorn_launcher -E production -c config/unicorn.conf.rb
   1964 be/4 messageb  611.83 K/s    0.00 B/s  ?unavailable?  redis-server *:6379
   1973 be/4 www-data  530.17 K/s  272.40 B/s  ?unavailable?  nginx: worker process
   2054 be/4 systemd-    8.78 K/s    7.45 K/s  ?unavailable?  postgres: 13/main: walwriter
   2056 be/4 systemd-  102.42 K/s    0.00 B/s  ?unavailable?  postgres: 13/main: stats collector
   2081 be/4 admin     817.20 B/s    0.00 B/s  ?unavailable?  unicorn master -E production -c config/unicorn.conf.rb
   2493 ?dif root      132.21 K/s    0.00 B/s  ?unavailable?  AliYunDun
   2504 be/2 root      740.32 K/s    0.00 B/s  ?unavailable?  AliYunDunMonitor
  45686 be/4 root       47.62 K/s    0.00 B/s  ?unavailable?  sshd: root@pts/0
  45816 be/4 root       36.98 K/s    0.00 B/s  ?unavailable?  top
  46146 be/4 root      357.52 K/s    0.00 B/s  ?unavailable?  python3 /usr/sbin/iotop -b -d 15 -P -o
  46160 be/4 root      267.34 K/s    0.00 B/s  ?unavailable?  sshd: root@pts/2
  46232 be/4 root      174.24 K/s    0.00 B/s  ?unavailable?  vmstat 5
  51903 be/4 admin    1569.22 K/s  272.40 B/s  ?unavailable?  unicorn worker[0] -E production -c config/unicorn.conf.rb
  51972 be/4 admin     175.84 K/s    0.00 B/s  ?unavailable?  unicorn worker[1] -E production -c config/unicorn.conf.rb
  60365 be/4 root      272.40 B/s    0.00 B/s  ?unavailable?  [kworker/u4:0-writeback]
  63081 be/4 root      272.40 B/s    0.00 B/s  ?unavailable?  [kworker/u4:4-events_unbound]
  63825 be/4 systemd-  673.02 K/s    0.00 B/s  ?unavailable?  postgres: 13/main: discourse discourse [local] idle
  64191 be/4 root       23.14 K/s    0.00 B/s  ?unavailable?  -bash

In effetti, sono riuscito a far crashare il sito web aggiornando rapidamente la homepage più volte con il tasto F5… Quindi, penso che sia molto probabile che si tratti di un problema con Discourse.

Output di top ora:

top - 13:36:47 up 18:03,  4 users,  load average: 86.10, 47.87, 19.63
Tasks: 174 total,   4 running, 170 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.2 us, 21.1 sy,  0.0 ni,  0.0 id, 76.3 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :   1668.6 total,     69.6 free,   1413.6 used,    185.4 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.     36.9 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     92 root      20   0       0      0      0 S  37.8   0.0 100:17.66 kswapd0
   1320 root      20   0 1236124   2320      0 S   4.0   0.1   4:18.47 containerd-shim
   1027 root      20   0 2281464  29160      0 S   2.6   1.7   2:25.38 dockerd
    805 root      20   0 1798676  11844      0 S   2.5   0.7   2:28.22 containerd
   2504 root      10 -10  129972  11660      0 D   2.1   0.7  27:34.39 AliYunDunMonito
     90 root       0 -20       0      0      0 R   1.5   0.0   1:58.75 kworker/1:1H-kblockd
   2493 root      10 -10   88144   2244      0 D   1.1   0.1  10:49.21 AliYunDun
  51989 root      20   0 1318960   8980      0 S   0.8   0.5   0:46.15 snapd
   1008 root      20   0 1276372   2584      0 S   0.7   0.2  11:16.56 argusagent
  46146 root      20   0   22320   9516   1908 D   0.5   0.6   0:23.57 iotop
  46160 root      20   0   17200   4968   2496 D   0.3   0.3   0:03.41 sshd
  45686 root      20   0   17200   5188   2716 D   0.3   0.3   0:04.21 sshd
    785 root      20   0   42324    876      0 S   0.2   0.1   3:41.24 AliYunDunUpdate
  45816 root      20   0   10500   3352   2544 R   0.2   0.2   0:26.01 top
  51903 admin     20   0  845708 458296      4 S   0.2  26.8   0:32.36 ruby
  53938 admin     25   5 5285240 378040      0 S   0.2  22.1   0:33.50 ruby
    723 root      20   0   19424    996      0 S   0.2   0.1   1:57.31 assist_daemon
    725 root      20   0  689584   3800      0 S   0.2   0.2   3:06.25 aliyun-service
   1964 message+  20   0   74800  13944      0 D   0.2   0.8   2:51.80 redis-server
   1974 www-data  20   0   57696   6136    772 R   0.2   0.4   0:36.37 nginx
   1975 www-data  20   0   53508   1520     72 S   0.2   0.1   0:45.76 nginx
   2053 systemd+  20   0  213244   6952   4988 D   0.2   0.4   0:27.47 postmaster
  51972 admin     20   0 5139692 329104      4 S   0.2  19.3   0:08.21 ruby
  64309 systemd+  20   0  213244   1956      0 D   0.2   0.1   0:00.15 postmaster
     22 root      20   0       0      0      0 S   0.1   0.0   0:09.66 ksoftirqd/1
    149 root       0 -20       0      0      0 I   0.1   0.0   0:06.26 kworker/0:1H-kblockd
   1973 www-data  20   0   56576   5088    768 D   0.1   0.3   0:35.23 nginx
   2052 systemd+  20   0  213468  34408  32340 D   0.1   2.0   0:30.59 postmaster
   2055 systemd+  20   0  213780   3244    932 D   0.1   0.2   0:29.32 postmaster
   2056 systemd+  20   0   68132   2256      0 D   0.1   0.1   0:15.54 postmaster
   2081 admin     20   0  585324 280488      4 S   0.1  16.4   0:57.44 ruby

Output di vmstat qui sotto:

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      0  80348    884 230624    0    0   538     6 1980 3661  1  1 99  0  0
 0  0      0  78232   2780 226576    0    0 17644    20 2510 4063  3  1 93  2  0
 3  0      0  93580    176 186012    0    0 34986    19 3329 4751 13  4 78  6  0
 0 29      0  82988    192 177628    0    0 127805    10 4930 6456  5  7 34 54  0
 0 30      0  85520    204 175124    0    0 120935     6 3768 6887  1  5  0 94  0
 3 37      0  89408    232 170836    0    0 122472    35 3876 7157  1  7  0 92  0
10 80      0  74004    220 186372    0    0 476674    36 4532 10212  0 35  0 64  0
11 89      0  71564    160 190284    0    0 388222     0 11098 27886  0 53  0 47  0
 0 100      0  73508    160 188484    0    0 209539     4 4726 11652  0 32  0 68  0

Non sono un esperto di Linux, ma non è il processo kswapd0 responsabile della gestione della memoria e dello scambio di swap? Perché ha un utilizzo così elevato della CPU sy quando swpd, si e so in vmstat sono tutti 0? Sono completamente perplesso.

11

È molto sospetto che tu abbia 2G di swap ma non ci sia utilizzo o attività di swap. Sospetterei delle impostazioni del tuo kernel. Ecco le mie: per favore, mostra tutte le tue, non scegliere solo quelle che ti fanno comodo!

head /proc/sys/vm/*
==> /proc/sys/vm/admin_reserve_kbytes <==
8192

==> /proc/sys/vm/block_dump <==
0
head: impossibile aprire '/proc/sys/vm/compact_memory' in lettura: Permesso negato

==> /proc/sys/vm/compact_unevictable_allowed <==
1

==> /proc/sys/vm/dirty_background_bytes <==
0

==> /proc/sys/vm/dirty_background_ratio <==
10

==> /proc/sys/vm/dirty_bytes <==
0

==> /proc/sys/vm/dirty_expire_centisecs <==
3000

==> /proc/sys/vm/dirty_ratio <==
20

==> /proc/sys/vm/dirty_writeback_centisecs <==
500

==> /proc/sys/vm/dirtytime_expire_seconds <==
43200

==> /proc/sys/vm/drop_caches <==
0

==> /proc/sys/vm/extfrag_threshold <==
500

==> /proc/sys/vm/hugepages_treat_as_movable <==
0

==> /proc/sys/vm/hugetlb_shm_group <==
0

==> /proc/sys/vm/laptop_mode <==
0

==> /proc/sys/vm/legacy_va_layout <==
0

==> /proc/sys/vm/lowmem_reserve_ratio <==
256     256     32      1

==> /proc/sys/vm/max_map_count <==
65530

==> /proc/sys/vm/memory_failure_early_kill <==
0

==> /proc/sys/vm/memory_failure_recovery <==
1

==> /proc/sys/vm/min_free_kbytes <==
45056

==> /proc/sys/vm/min_slab_ratio <==
5

==> /proc/sys/vm/min_unmapped_ratio <==
1

==> /proc/sys/vm/mmap_min_addr <==
65536

==> /proc/sys/vm/mmap_rnd_bits <==
28

==> /proc/sys/vm/mmap_rnd_compat_bits <==
8

==> /proc/sys/vm/nr_hugepages <==
0

==> /proc/sys/vm/nr_hugepages_mempolicy <==
0

==> /proc/sys/vm/nr_overcommit_hugepages <==
0

==> /proc/sys/vm/numa_stat <==
1

==> /proc/sys/vm/numa_zonelist_order <==
Node

==> /proc/sys/vm/oom_dump_tasks <==
1

==> /proc/sys/vm/oom_kill_allocating_task <==
0

==> /proc/sys/vm/overcommit_kbytes <==
0

==> /proc/sys/vm/overcommit_memory <==
1

==> /proc/sys/vm/overcommit_ratio <==
50

==> /proc/sys/vm/page-cluster <==
3

==> /proc/sys/vm/panic_on_oom <==
0

==> /proc/sys/vm/percpu_pagelist_fraction <==
0

==> /proc/sys/vm/stat_interval <==
1

==> /proc/sys/vm/stat_refresh <==

==> /proc/sys/vm/swappiness <==
60

==> /proc/sys/vm/user_reserve_kbytes <==
29305

==> /proc/sys/vm/vfs_cache_pressure <==
100

==> /proc/sys/vm/watermark_scale_factor <==
10

==> /proc/sys/vm/zone_reclaim_mode <==
0

Modifica: per favore, esegui anche questi e pubblica l’output

swapon
free
uname -a
df -T
1 Mi Piace
12 
root@iZj6cgi365ov99veqodfgnZ:~# head /proc/sys/vm/*
==> /proc/sys/vm/admin_reserve_kbytes <==
8192

==> /proc/sys/vm/compaction_proactiveness <==
20
head: impossibile aprire '/proc/sys/vm/compact_memory' in lettura: Permesso negato

==> /proc/sys/vm/compact_unevictable_allowed <==
1

==> /proc/sys/vm/dirty_background_bytes <==
0

==> /proc/sys/vm/dirty_background_ratio <==
10

==> /proc/sys/vm/dirty_bytes <==
0

==> /proc/sys/vm/dirty_expire_centisecs <==
3000

==> /proc/sys/vm/dirty_ratio <==
30

==> /proc/sys/vm/dirtytime_expire_seconds <==
43200

==> /proc/sys/vm/dirty_writeback_centisecs <==
500
head: impossibile aprire '/proc/sys/vm/drop_caches' in lettura: Permesso negato

==> /proc/sys/vm/extfrag_threshold <==
500

==> /proc/sys/vm/hugetlb_shm_group <==
0

==> /proc/sys/vm/laptop_mode <==
0

==> /proc/sys/vm/legacy_va_layout <==
0

==> /proc/sys/vm/lowmem_reserve_ratio <==
256     256     32      0       0

==> /proc/sys/vm/max_map_count <==
65530

==> /proc/sys/vm/memory_failure_early_kill <==
0

==> /proc/sys/vm/memory_failure_recovery <==
1

==> /proc/sys/vm/min_free_kbytes <==
45056

==> /proc/sys/vm/min_slab_ratio <==
5

==> /proc/sys/vm/min_unmapped_ratio <==
1

==> /proc/sys/vm/mmap_min_addr <==
65536

==> /proc/sys/vm/mmap_rnd_bits <==
28

==> /proc/sys/vm/mmap_rnd_compat_bits <==
8

==> /proc/sys/vm/nr_hugepages <==
0

==> /proc/sys/vm/nr_hugepages_mempolicy <==
0

==> /proc/sys/vm/nr_overcommit_hugepages <==
0

==> /proc/sys/vm/numa_stat <==
1

==> /proc/sys/vm/numa_zonelist_order <==
Node

==> /proc/sys/vm/oom_dump_tasks <==
1

==> /proc/sys/vm/oom_kill_allocating_task <==
0

==> /proc/sys/vm/overcommit_kbytes <==
0

==> /proc/sys/vm/overcommit_memory <==
0

==> /proc/sys/vm/overcommit_ratio <==
50

==> /proc/sys/vm/page-cluster <==
3

==> /proc/sys/vm/page_lock_unfairness <==
5

==> /proc/sys/vm/panic_on_oom <==
0

==> /proc/sys/vm/percpu_pagelist_high_fraction <==
0

==> /proc/sys/vm/stat_interval <==
1

==> /proc/sys/vm/stat_refresh <==

==> /proc/sys/vm/swappiness <==
0

==> /proc/sys/vm/unprivileged_userfaultfd <==
0

==> /proc/sys/vm/user_reserve_kbytes <==
50778

==> /proc/sys/vm/vfs_cache_pressure <==
100

==> /proc/sys/vm/watermark_boost_factor <==
15000

==> /proc/sys/vm/watermark_scale_factor <==
10

==> /proc/sys/vm/zone_reclaim_mode <==
0

root@iZj6cgi365ov99veqodfgnZ:~# swapon
NAME      TYPE SIZE USED PRIO
/swapfile file   2G   0B   -2

root@iZj6cgi365ov99veqodfgnZ:~# free
              total        used        free      shared  buff/cache   available
Mem:        1708636      984352       79376       38344      644908      490004
Swap:       2097148           0     2097148

root@iZj6cgi365ov99veqodfgnZ:~# uname -a
Linux iZj6cgi365ov99veqodfgnZ 5.15.0-86-generic #96-Ubuntu SMP Wed Sep 20 08:23:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

root@iZj6cgi365ov99veqodfgnZ:~# df -T
Filesystem     Type    1K-blocks     Used Available Use% Mounted on
tmpfs          tmpfs      170864     1164    169700   1% /run
/dev/vda3      ext4     61540412 19791160  39020044  34% /
tmpfs          tmpfs      854316        0    854316   0% /dev/shm
tmpfs          tmpfs        5120        0      5120   0% /run/lock
/dev/vda2      vfat       201615     6186    195429   4% /boot/efi
tmpfs          tmpfs      170860        4    170856   1% /run/user/0
overlay        overlay  61540412 19791160  39020044  34% /var/lib/docker/overlay2/7754829d0ad68c8acc8b50ed96ae87d8d882a996b87fe0b6821827e527487b62/merged
13

Grazie, è ottimo. In qualche modo hai impostato swappiness a zero, il che è quasi certamente la maggior parte del tuo problema.

Ma ci sono tre impostazioni che vale la pena impostare correttamente: una è swappiness e due sono menzionate in Configurazione di distribuzione di Discourse opinabile di MKJ
/proc/sys/vm/overcommit_memory
/sys/kernel/mm/transparent_hugepage/enabled
/proc/sys/vm/swappiness

Puoi impostarli una volta, ma dovresti anche assicurarti che siano impostati all’avvio: vedi il post di MJK e controlla quei file prima di sovrascriverli.

Sospetto che qualcosa stia accadendo all’avvio per impostare swappiness a zero. Forse il tuo provider di hosting sta cercando di scoraggiare lo swapping su SSD. Ma devi avere lo swap, altrimenti devi almeno aggiornare a 4G di RAM.

Forse prova
egrep -r swappiness /etc/
per cercare di trovare dove viene impostato.

Ci sono consigli altrove su questo forum per impostare swappiness a 10: io preferisco lasciarlo al valore predefinito di 60.

1 Mi Piace
14

Mi dispiace… non sono molto esperto di Linux. Potresti insegnarmi specificamente come configurarlo?
Non ho mai modificato manualmente alcuna impostazione di sistema. Tuttavia, penso che il provider di hosting possa limitare lo swap perché questo server sembra funzionare su HDD (a giudicare dalle 2k IOPS massime).

Fare queste cose può modificare permanentemente le impostazioni che hai menzionato?

esegui:

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf

e cambia vm.swapiness = 60 in /etc/sysctl.conf

ora: (ho riavviato dopo aver modificato tutte le impostazioni. I comandi seguenti vengono eseguiti dopo il riavvio)

root@iZj6cgi365ov99veqodfgnZ:~# head /proc/sys/vm/*
==> /proc/sys/vm/admin_reserve_kbytes <==
8192

==> /proc/sys/vm/compaction_proactiveness <==
20
head: cannot open '/proc/sys/vm/compact_memory' for reading: Permission denied

==> /proc/sys/vm/compact_unevictable_allowed <==
1

==> /proc/sys/vm/dirty_background_bytes <==
0

==> /proc/sys/vm/dirty_background_ratio <==
10

==> /proc/sys/vm/dirty_bytes <==
0

==> /proc/sys/vm/dirty_expire_centisecs <==
3000

==> /proc/sys/vm/dirty_ratio <==
30

==> /proc/sys/vm/dirtytime_expire_seconds <==
43200

==> /proc/sys/vm/dirty_writeback_centisecs <==
500
head: cannot open '/proc/sys/vm/drop_caches' for reading: Permission denied

==> /proc/sys/vm/extfrag_threshold <==
500

==> /proc/sys/vm/hugetlb_shm_group <==
0

==> /proc/sys/vm/laptop_mode <==
0

==> /proc/sys/vm/legacy_va_layout <==
0

==> /proc/sys/vm/lowmem_reserve_ratio <==
256     256     32      0       0

==> /proc/sys/vm/max_map_count <==
65530

==> /proc/sys/vm/memory_failure_early_kill <==
0

==> /proc/sys/vm/memory_failure_recovery <==
1

==> /proc/sys/vm/min_free_kbytes <==
45056

==> /proc/sys/vm/min_slab_ratio <==
5

==> /proc/sys/vm/min_unmapped_ratio <==
1

==> /proc/sys/vm/mmap_min_addr <==
65536

==> /proc/sys/vm/mmap_rnd_bits <==
28

==> /proc/sys/vm/mmap_rnd_compat_bits <==
8

==> /proc/sys/vm/nr_hugepages <==
0

==> /proc/sys/vm/nr_hugepages_mempolicy <==
0

==> /proc/sys/vm/nr_overcommit_hugepages <==
0

==> /proc/sys/vm/numa_stat <==
1

==> /proc/sys/vm/numa_zonelist_order <==
Node

==> /proc/sys/vm/oom_dump_tasks <==
1

==> /proc/sys/vm/oom_kill_allocating_task <==
0

==> /proc/sys/vm/overcommit_kbytes <==
0

==> /proc/sys/vm/overcommit_memory <==
1

==> /proc/sys/vm/overcommit_ratio <==
50

==> /proc/sys/vm/page-cluster <==
3

==> /proc/sys/vm/page_lock_unfairness <==
5

==> /proc/sys/vm/panic_on_oom <==
0

==> /proc/sys/vm/percpu_pagelist_high_fraction <==
0

==> /proc/sys/vm/stat_interval <==
1

==> /proc/sys/vm/stat_refresh <==


==> /proc/sys/vm/swappiness <==
60

==> /proc/sys/vm/unprivileged_userfaultfd <==
0

==> /proc/sys/vm/user_reserve_kbytes <==
50778

==> /proc/sys/vm/vfs_cache_pressure <==
100

==> /proc/sys/vm/watermark_boost_factor <==
15000

==> /proc/sys/vm/watermark_scale_factor <==
10

==> /proc/sys/vm/zone_reclaim_mode <==
0

root@iZj6cgi365ov99veqodfgnZ:~# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

Sembra che funzioni bene! Grazie mille a tutti per l’aiuto!

2 Mi Piace
15

Ottimo progresso! Raccomando

# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.