Hohe CPU- und Disk-Auslastung nach Wiederherstellung von einem fehlgeschlagenen Update.

Installation
1

Nachdem ich die Veröffentlichung von 3.3.0-beta1 entdeckt hatte, habe ich meine Discourse-Instanz sofort über die Weboberfläche aktualisiert.

Während des Update-Vorgangs blieben die Protokolle der Weboberfläche jedoch über fünfzehn Minuten lang ohne weitere Ausgabe stehen (ich erinnere mich, dass die letzte Ausgabe eine Reihe von wachsenden Ellipsen war? Das könnte sein, ich bin mir nicht ganz sicher). Etwa 2 Stunden später überprüfte ich den Serverstatus über die Cloud-Plattform und vermutete, dass er eingefroren war, also führte ich einen Soft-Reboot über die Cloud-Plattform durch.

Nach dem Neustart führte ich sofort ein Discourse-Backup über die Befehlszeile durch, lud das Backup und die app.yml lokal herunter und installierte dann Discourse komplett neu (natürlich die neueste Version). Danach lud ich das Backup hoch und initiierte den Wiederherstellungsprozess über die Befehlszeile.

Die Wiederherstellung war erfolgreich, aber jetzt hat mein Discourse ernsthafte Leistungsprobleme. Zuvor überschritt die CPU-Auslastung bei normaler Nutzung 10 % nicht, aber jetzt steigt sie selbst in Randzeiten auf etwa 30 %, und auch die Festplattenlesevorgänge sind relativ hoch. Was noch schlimmer ist, manchmal stürzt der Server unerklärlicherweise ab, mit Festplattenlesevorgängen von etwa 1900 pro Sekunde (das ist das Limit meines Cloud-Servers) und die CPU ist zu über 40 % im Wartezustand. Webseiten können nicht geladen werden und zeigen Verbindungs-Timeouts an. Im Moment führe ich vmstat und top aus, aber leider habe ich die Ausgabe nicht aufbewahrt. Ich erinnere mich, dass der Swap-IO fast null war, was reine Festplattenlesevorgänge anzeigte. Die Anzahl der blockierten Threads überschritt 100.

Ich vermute, dass dieses fehlgeschlagene Update möglicherweise einige Schäden verursacht hat, möglicherweise an Daten innerhalb des Backups, anstatt an der Software selbst. Gibt es eine Möglichkeit, – äh, ich bin mir nicht sicher? – einen Cache oder ähnliches zu aktualisieren oder zu löschen? Oder vielleicht… das Update erneut auszuführen? (Schließlich sind Discourse-Updates recht häufig und es kann fast jederzeit aktualisiert werden.)

Als vorübergehende Lösung habe ich einen Software-Watchdog installiert, der bei hoher Last automatisch neu startet. Dies ist jedoch letztendlich keine langfristige Lösung, und ich habe hier keine ähnlichen Probleme gefunden; offensichtlich ist es kein Problem mit der Discourse-Software selbst. Ich frage mich, wie ich das angehen kann.

Wenn Sie möchten, dass ich einige Befehle auf dem Server ausführe, um seinen Status bei hoher Last zu überprüfen, fragen Sie einfach. Ich werde mein Bestes tun, um meine SSH-Verbindung aufrechtzuerhalten und diese Daten zu erhalten, ohne neu zu starten.

2

Wie sieht Ihre Sidekiq-Warteschlange aus? Es könnte einfach sein, dass alle Beiträge neu gebacken werden und sich die Last irgendwann beruhigt, sobald der Rückstand abgearbeitet ist. D. h. die Situation sollte vorübergehend sein.

Das ist mir in letzter Zeit ein paar Mal passiert. Jedes Mal habe ich manuell neu gestartet und dann einen Wiederaufbau über die Befehlszeile durchgeführt. Offensichtlich keine gute Lösung auf lange Sicht und riskant.

Dies ist ein Zeichen dafür, dass Ihr Computer nicht mehr genügend Speicher hat. Erwägen Sie, den Swap zu erhöhen, um mit den Spitzen fertig zu werden.

Ich stelle fest, dass ich jetzt eine 4-GB-Maschine plus 3 GB Swap benötige, um Online-Updates auszuführen: Wie viel Speicher haben Sie?

3

Ähm… eigentlich hatte er kurz nach der Wiederherstellung keine extrem hohen Lasten, was ich für normal halte. Aber in meinem Fall, nachdem die Last nach der Wiederherstellung auf etwa 2 % gesunken war, als ich einige Bearbeitungen an der Weboberfläche vornahm, hörte die Seite plötzlich nach einer Aktion auf zu laden. Bei der Überprüfung der Cloud-Server-Plattform waren CPU und Festplatten-Lesevorgänge sehr hoch. Ich glaube nicht, dass dies ein Problem mit dem erneuten Backen aller Beiträge ist.

Da mein Server derzeit in einem normalen Zustand ist, hier ist die Sidekiq-Oberfläche:

image
image1366×607 68.5 KB

image
image1229×314 48 KB

4

Ich habe 2 GB physischen Arbeitsspeicher und 2 GB Swap. Es scheint, als ob Swap während des Discourse-Installationsprozesses automatisch aktiviert wurde? Jedenfalls habe ich ihn nicht manuell konfiguriert.

Ich habe jetzt manuell Swap auf insgesamt 6 GB hinzugefügt.

5

Das ist also Ihr Problem. Nach meinen jüngsten Erfahrungen scheint der Webkompilierungsprozess viel mehr Ressourcen zu verbrauchen, und Sie könnten mit einem viel größeren Swap experimentieren oder auf einen größeren Server migrieren.

6

Übrigens, bei meinen früheren Versuchen, Backups über die Webschnittstelle durchzuführen, blieben die Protokolle manchmal hängen. Jetzt führe ich alle Backups und Wiederherstellungen über die Befehlszeile aus (außer automatischen Backups, die nie fehlgeschlagen sind und gut funktionieren). Ich frage mich, ob dies ein häufiges Problem ist? Gibt es einen Befehl, um ein Update durchzuführen? Sollte ich zukünftig weiterhin Updates über die Befehlszeile durchführen? Würde dies möglicherweise die Erfolgsquote erhöhen?

7

Im täglichen Gebrauch stelle ich auch eine deutliche Zunahme der Ladezeiten von Webseiten im Vergleich zu früher fest, und es ist höchstwahrscheinlich kein Netzwerkproblem, sondern ein Leistungsproblem. Hier sind die Leistungsdaten beim Laden der 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

Das sieht verdächtig aus – könnte die Ursache sein oder auch nicht. Etwas (wahrscheinlich) verursacht eine riesige Menge an Festplattenlesevorgängen. AliYunDun scheint das Tool des Cloud-Anbieters zu sein. AliYunDunMonitor hängt (möglicherweise) auf Festplattenwarteschleifen, läuft mit erhöhter Priorität und hat viel CPU-Zeit verbraucht.

Ich sehe, dass jemand irgendwo ein Skript geschrieben hat, um solche Prozesse zu beenden. Der Ton ist wütend. (Ich kann nicht sagen, ob dieses Skript sicher ist oder eine gute Idee.)

Es ist aber auch möglich, dass ein Discourse-Prozess all die Festplattenlesevorgänge verursacht.

Versuchen Sie vielleicht

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

und beobachten Sie es, bis Sie Ihren Freeze haben.

10

Okay und hier ist die Ausgabe von iotop, wenn es einfriert:

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

Tatsächlich habe ich es geschafft, die Website zum Absturz zu bringen, indem ich die Homepage mehrmals mit der F5-Taste schnell aktualisiert habe… Daher denke ich, dass es sich höchstwahrscheinlich um ein Problem mit Discourse handelt.

top-Ausgabe jetzt:

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

vmstat-Ausgabe unten:

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 0  0      0  80348    884 230624    0    0   538     6 1980 3661  1  1 99  0  0\n 0  0      0  78232   2780 226576    0    0 17644    20 2510 4063  3  1 93  2  0\n 3  0      0  93580    176 186012    0    0 34986    19 3329 4751 13  4 78  6  0\n 0 29      0  82988    192 177628    0    0 127805    10 4930 6456  5  7 34 54  0\n 0 30      0  85520    204 175124    0    0 120935     6 3768 6887  1  5  0 94  0\n 3 37      0  89408    232 170836    0    0 122472    35 3876 7157  1  7  0 92  0\n10 80      0  74004    220 186372    0    0 476674    36 4532 10212  0 35  0 64  0\n11 89      0  71564    160 190284    0    0 388222     0 11098 27886  0 53  0 47  0\n 0 100      0  73508    160 188484    0    0 209539     4 4726 11652  0 32  0 68  0\n```
Ich bin kein Experte für Linux, aber ist der Prozess kswapd0 nicht für die Verwaltung des Speichers und des Swaps zuständig? Warum hat er eine so hohe sy CPU-Auslastung, wenn swpd, si und so in vmstat alle 0 sind? Ich bin völlig ratlos.
11

Es ist sehr verdächtig, dass Sie 2 GB Swap haben, aber keine Swap-Nutzung und keine Swap-Aktivität. Ich würde Ihre Kernel-Einstellungen vermuten. Hier sind meine - bitte zeigen Sie alle Ihre, bitte wählen Sie nicht aus!

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

==> /proc/sys/vm/block_dump <==
0
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 <==
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

Bearbeiten: Bitte führen Sie auch diese aus und posten Sie die Ausgabe

swapon
free
uname -a
df -T
1 „Gefällt mir“
12 
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 <==
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
              Gesamt    genutzt    frei   shared Puffer/Cache verfügbar
Speicher:     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
Dateisystem    Typ    1K-Blöcke  Benutzt Verf. Verw% Eingehängt auf
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

Danke, das ist großartig. Irgendwie ist Ihre Swappiness auf Null gesetzt, was mit ziemlicher Sicherheit den Großteil Ihres Problems ausmacht.

Es gibt jedoch drei Einstellungen, die es wert sind, richtig eingestellt zu werden: Eine ist Swappiness und zwei davon werden in MKJ’s Opinionated Discourse Deployment Configuration erwähnt.
/proc/sys/vm/overcommit_memory
/sys/kernel/mm/transparent_hugepage/enabled
/proc/sys/vm/swappiness

Sie können diese einmal einstellen, aber Sie sollten auch sicherstellen, dass sie beim Booten eingestellt werden - siehe MJK’s Beitrag, und überprüfen Sie diese Dateien, bevor Sie sie überschreiben.

Ich vermute, dass beim Booten etwas passiert, um die Swappiness auf Null zu setzen. Möglicherweise versucht Ihr Hosting-Anbieter, das Swapping auf SSD zu verhindern. Aber Sie müssen Swap haben, oder Sie müssen mindestens auf 4G RAM aufrüsten.

Versuchen Sie vielleicht
egrep -r swappiness /etc/
um herauszufinden, wo es eingestellt wird.

Es gibt anderswo in diesem Forum Ratschläge, die Swappiness auf 10 zu setzen - ich ziehe es vor, sie beim Standardwert von 60 zu belassen.

1 „Gefällt mir“
14

Entschuldigung … Ich bin nicht sehr gut in Linux. Könnten Sie mir speziell beibringen, wie ich es einrichte?
Ich habe noch nie manuell Systemeinstellungen geändert. Ich glaube jedoch, dass der Hosting-Anbieter möglicherweise Swap einschränkt, da dieser Server anscheinend auf HDD läuft (nach den maximalen 2k IOPS zu urteilen).

Können diese Dinge die von Ihnen erwähnten Einstellungen dauerhaft ändern?

Ausführen:

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

und ändern Sie vm.swapiness = 60 in /etc/sysctl.conf

Jetzt: (Ich habe nach der Änderung aller Einstellungen neu gestartet. Die folgenden Befehle werden nach dem Neustart ausgeführt)

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

Es scheint gut zu laufen! Vielen Dank an alle für Ihre Hilfe!

2 „Gefällt mir“
15

Das sind gute Fortschritte! Ich empfehle

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