Discourse verbraucht nicht viel RAM

Hallo!

Ich habe gestern geprüft, und die Seite war in Ordnung. Als ich heute Morgen aufwachte, war sie mit dem Fehler 502 Bad Gateway nicht erreichbar. Hier ist die monitor.log monitor.txt (9,4 MB).

Wow… warum so viel Java? Sieht aus wie mein Jitsi-Server einmal:exploding_head:

Es scheint auch, dass du deinen Host als Mailserver verwendest. Ich habe meinen schließlich von der App getrennt, sodass es einfacher ist, ihn im Notfall wiederherzustellen (und ihn ordentlich zu halten, so nah wie möglich an einer Standard-Produktionsinstallation). Eine sehr kleine Instanz für die E-Mail mit einer Floating-IP könnte auch einfacher zu überwachen sein, was die Reputation betrifft, und nur marginal teurer sein.

OK, mal sehen… zuerst suchen wir mit grep nach „average":

 06:24:13 up 3 days,  8:13,  0 users,  load average: 0.01, 0.05, 0.08
 06:34:33 up 3 days,  8:23,  0 users,  load average: 12.89, 11.68, 6.35

Offensichtlich ist etwas explodiert, was die Anzahl der ausführbaren Prozesse betrifft, kurz vor 06:34.

Eine etwas breitere Suche mit grep zeigt, dass sich der Speicherverbrauch eigentlich nicht verändert hat:

 06:24:13 up 3 days,  8:13,  0 users,  load average: 0.01, 0.05, 0.08
              total        used        free      shared  buff/cache   available
Mem:        8167548     3513172     3241404      371940     1412972     4512016
Swap:      10485756           0    10485756
--
 06:34:33 up 3 days,  8:23,  0 users,  load average: 12.89, 11.68, 6.35
              total        used        free      shared  buff/cache   available
Mem:        8167548     3110612     1351844      373268     3705092     4812672
Swap:      10485756           0    10485756

Tatsächlich ist der Speicherverbrauch sogar gesunken, vielleicht ist also etwas abgestürzt:

 06:13:53 up 3 days,  8:02,  0 users,  load average: 0.04, 0.16, 0.15
              total        used        free      shared  buff/cache   available
Mem:        8167548     3505540     3259744      371932     1402264     4519680
 06:24:13 up 3 days,  8:13,  0 users,  load average: 0.01, 0.05, 0.08
              total        used        free      shared  buff/cache   available
Mem:        8167548     3513172     3241404      371940     1412972     4512016
 06:34:33 up 3 days,  8:23,  0 users,  load average: 12.89, 11.68, 6.35
              total        used        free      shared  buff/cache   available
Mem:        8167548     3110612     1351844      373268     3705092     4812672
 06:44:53 up 3 days,  8:33,  0 users,  load average: 13.64, 13.25, 9.89
              total        used        free      shared  buff/cache   available
Mem:        8167548     3093212     3618984      373276     1455352     4840140
 06:55:13 up 3 days,  8:44,  0 users,  load average: 11.62, 12.70, 11.42
              total        used        free      shared  buff/cache   available
Mem:        8167548     3140580     3366628      373352     1660340     4792440

Es sieht so aus, als hätten sich die Unicorns neu gestartet:

Thu Aug  5 06:24:13 CEST 2021
 06:24:13 up 3 days,  8:13,  0 users,  load average: 0.01, 0.05, 0.08
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     30389  0.0  0.0   2160  1148 ?        Ss   Aug03   0:00          \_ runsv unicorn
x        13329  0.0  0.0  15132  3712 ?        S    Aug04   0:26              \_ /bin/bash config/unicorn_launcher -E production -c config/unicorn.conf.rb
x        13365  0.0  3.0 542036 251584 ?       Sl   Aug04   0:23                  \_ unicorn master -E production -c config/unicorn.conf.rb
x        13846  0.6  4.5 9129356 371852 ?      SNl  Aug04   4:19                  |   \_ sidekiq 6.2.1 discourse [0 of 5 busy]
x        13858  0.0  3.9 8971616 323264 ?      Sl   Aug04   0:18                  |   \_ unicorn worker[0] -E production -c config/unicorn.conf.rb
x        13870  0.0  4.0 8975712 330660 ?      Sl   Aug04   0:20                  |   \_ unicorn worker[1] -E production -c config/unicorn.conf.rb
x        13889  0.0  4.1 8979808 337180 ?      Sl   Aug04   0:20                  |   \_ unicorn worker[2] -E production -c config/unicorn.conf.rb
x        29760  0.0  0.0  13708  2220 ?        S    06:24   0:00                  \_ sleep 1

Thu Aug  5 06:34:33 CEST 2021
 06:34:33 up 3 days,  8:23,  0 users,  load average: 12.89, 11.68, 6.35
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     30389  0.0  0.0   2160  1148 ?        Ss   Aug03   0:00          \_ runsv unicorn
x         4638  0.4  0.0  15132  3784 ?        S    06:32   0:00              \_ /bin/bash config/unicorn_launcher -E production -c config/unicorn.conf.rb
x         4642 11.1  2.8 439636 233240 ?       Sl   06:32   0:11                  \_ unicorn master -E production -c config/unicorn.conf.rb
x         4822 13.1  3.7 8877408 309844 ?      Sl   06:33   0:10                  |   \_ unicorn worker[1] -E production -c config/unicorn.conf.rb
x         5025 15.6  3.7 8873312 310264 ?      Sl   06:33   0:10                  |   \_ unicorn worker[0] -E production -c config/unicorn.conf.rb
x         5065 20.6  3.9 8922504 320740 ?      SNl  06:33   0:11                  |   \_ sidekiq 6.2.1 discourse [0 of 5 busy]
x         5639  0.0  0.0  13708  2264 ?        S    06:34   0:00                  \_ sleep 1

Und es sieht so aus, als hätte Apache Schwierigkeiten beim Starten:

Thu Aug  5 06:24:13 CEST 2021
 06:24:13 up 3 days,  8:13,  0 users,  load average: 0.01, 0.05, 0.08
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     13730  0.0  0.1 225016 15840 ?        Ss   Aug02   0:17 /usr/sbin/apache2 -k start
www-data 10232  0.0  0.1 1352372 10972 ?       Sl   Aug03   0:00  \_ /usr/sbin/apache2 -k start
www-data 27998  0.0  0.1 228880  9608 ?        S    Aug04   0:01  \_ /usr/sbin/apache2 -k start
www-data 28000  0.0  0.3 3036536 27796 ?       Sl   Aug04   0:53  \_ /usr/sbin/apache2 -k start
www-data 28002  0.0  0.3 2904772 26524 ?       Sl   Aug04   0:50  \_ /usr/sbin/apache2 -k start
www-data 28185  0.0  0.1 762472 10952 ?        Sl   Aug04   0:00  \_ /usr/sbin/apache2 -k start

Thu Aug  5 06:34:33 CEST 2021
 06:34:33 up 3 days,  8:23,  0 users,  load average: 12.89, 11.68, 6.35
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     13730  0.0  0.1 225024 15856 ?        Ss   Aug02   0:17 /usr/sbin/apache2 -k start
www-data 10232  0.0  0.1 1352372 10972 ?       Sl   Aug03   0:00  \_ /usr/sbin/apache2 -k start
www-data 28185  0.0  0.1 762472 10952 ?        Sl   Aug04   0:00  \_ /usr/sbin/apache2 -k start
www-data 30794  0.0  0.1 228888  9620 ?        S    06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 31490  0.0  0.1 344564 10852 ?        Sl   06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 32095  0.0  0.1 500228 10888 ?        Sl   06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 32215 83.2  0.1 369152 10876 ?        Sl   06:25   7:26  \_ /usr/sbin/apache2 -k start
www-data 32284  0.0  0.1 229400  9936 ?        S    06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 32382  187  0.1 410136 10916 ?        Sl   06:25  16:31  \_ /usr/sbin/apache2 -k start
www-data 32410  0.0  0.1 229400  9936 ?        S    06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 32545  0.0  0.1 229400  9936 ?        S    06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data  2106  0.0  0.1 3032348 11396 ?       Sl   06:27   0:00  \_ /usr/sbin/apache2 -k start
www-data  2240  0.0  0.1 2901012 11416 ?       Sl   06:27   0:00  \_ /usr/sbin/apache2 -k start
www-data  2241  0.0  0.1 2901184 14220 ?       Sl   06:27   0:00  \_ /usr/sbin/apache2 -k start

Thu Aug  5 06:44:53 CEST 2021
 06:44:53 up 3 days,  8:33,  0 users,  load average: 13.64, 13.25, 9.89
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     13730  0.0  0.1 225024 15856 ?        Ss   Aug02   0:17 /usr/sbin/apache2 -k start
www-data 10232  0.0  0.1 1352372 10972 ?       Sl   Aug03   0:00  \_ /usr/sbin/apache2 -k start
www-data 28185  0.0  0.1 762472 10952 ?        Sl   Aug04   0:00  \_ /usr/sbin/apache2 -k start
www-data 30794  0.0  0.1 228888  9620 ?        S    06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 31490  0.0  0.1 344564 10852 ?        Sl   06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 32095  0.0  0.1 500228 10888 ?        Sl   06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 32215 82.1  0.1 369152 10876 ?        Sl   06:25  15:50  \_ /usr/sbin/apache2 -k start
www-data 32284  0.0  0.1 229400  9936 ?        S    06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 32382  188  0.1 410136 10916 ?        Sl   06:25  36:10  \_ /usr/sbin/apache2 -k start
www-data 32410  0.0  0.1 229400  9936 ?        S    06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data 32545  0.0  0.1 229400  9936 ?        S    06:25   0:00  \_ /usr/sbin/apache2 -k start
www-data  2106  0.0  0.1 3032348 11396 ?       Sl   06:27   0:00  \_ /usr/sbin/apache2 -k start
www-data  2240  0.0  0.1 2901012 11416 ?       Sl   06:27   0:00  \_ /usr/sbin/apache2 -k start
www-data  2241  0.0  0.1 2901184 14432 ?       Sl   06:27   0:00  \_ /usr/sbin/apache2 -k start

Beachten Sie, wie viele geforkte Apache-Prozesse vorhanden sind und dass einer davon 83 % der CPU-Leistung verbraucht und ein anderer 188 %. Da stimmt etwas nicht.

Aber ich bin mir nicht sicher, was ich mit dieser Erkenntnis anfangen soll.

Vielleicht lohnt es sich auch zu prüfen, ob der Kernel kürzlich einen Prozess aus einem bestimmten Grund beendet hat:
dmesg -T | egrep -i kille

Bei der Ausführung dieses Befehls erhalte ich keine Ausgabe.

Ich denke, das liegt daran, dass ein Freund mich von MPM Event auf MPM prefork umgestellt hat. Apache nutzt seitdem deutlich mehr Ressourcen, aber seit dem Wechsel zu Discourse sind keine Seiten abgestürzt oder beschädigt worden. Ich habe gerade wieder auf MPM prefork umgestellt. Vielleicht hilft das?

Ich habe herausgefunden, dass es sich bei Java anscheinend um den Varnish-Cache handelt. Ich habe den Prozessbaum geöffnet, und die Basis ist Varnish, was viel mehr Sinn ergibt als Java :smiley:

1 „Gefällt mir“

Das MPM-Event-Modul ermöglicht es Apache, multithreaded zu laufen und dadurch mehr Besucher zu bedienen. Es muss mit einem separaten PHP-Dienst kombiniert werden, der heutzutage üblicherweise PHP-FPM ist. Prefork kann die Leistung von Apache und PHP einschränken, wenn Ihr Server stark ausgelastet ist. Wenn Event zu viele Ressourcen verbraucht, liegt dies höchstwahrscheinlich an einer schlecht konfigurierten FPM-Konfiguration in Verbindung mit Event, aber eine nicht optimierte MPM-Event-Konfiguration kann ebenfalls problematisch sein.

Prefork funktioniert gut für Server ohne viel gleichzeitigen Datenverkehr, doch der Standard für Apache ist heutzutage Event/FPM.

Ich denke, das ist eine gute Sache…

Ok, danke für die Hilfe :slight_smile:

Ich bin wieder auf MPM prefork umgestiegen und Apache ist seit 3 Tagen nicht mehr abgestürzt. Ich hoffe, das war’s und alles ist jetzt behoben. Danke für all die Hilfe :slight_smile:

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