Prozess "/opt/otrs/bin/c" triggert OOM Killer

[khaed]

Hallo,

Ich würde um Hilfe bei einem Problem in unserem Znuny LTS 6.5.15 ersuchen, welches auf einem Debian 11.11 läuft, bei dem viele "/opt/otrs/bin/c" im Kontext des Users www-data den gesamten Arbeitsepeicher belegen und schlussendlich den OOM Killer triggern, der dann auch den Apache Webserver beendet.

In der /var/log/messages tauchen dann diese Blöcke auf:

Code: Select all

Aug  1 14:59:38 otrs-2017 kernel: [289662.428858] /opt/otrs/bin/c invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Aug  1 14:59:38 otrs-2017 kernel: [289662.428882]  oom_kill_process.cold+0xb/0x10
Aug  1 14:59:38 otrs-2017 kernel: [289662.429008] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
Aug  1 14:59:38 otrs-2017 kernel: [289662.429105] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/apache2.service,task=/opt/otrs/bin/c,pid=184925,uid=33
Aug  1 14:59:45 otrs-2017 kernel: [289669.170461] oom_reaper: reaped process 184925 (/opt/otrs/bin/c), now anon-rss:0kB, file-rss:0kB, shmem-rss:156kB

Ich hatte gerade das Vergnügen es live miterleben zu können, in top sieht es folgendermaßen aus:

Code: Select all

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     93 root      20   0       0      0      0 R  99.3   0.0   2:24.95 kswapd0
3521575 www-data  20   0   49.2g   6.5g   5184 D  12.0  20.8   0:25.94 /opt/otrs/bin/c
3526879 www-data  20   0   24.7g   6.7g   5376 D  12.0  21.3   0:25.27 /opt/otrs/bin/c
3526437 www-data  20   0   24.7g   9.3g   5360 R  10.6  29.6   0:26.04 /opt/otrs/bin/c
3523628 www-data  20   0   24.8g   6.0g   5184 R  10.3  19.2   0:26.01 /opt/otrs/bin/c
3527029 www-data  20   0  452144 101780   7820 S   3.0   0.3   0:03.69 /usr/sbin/apach
3527587 www-data  20   0  469016  70452   6748 S   1.0   0.2   0:03.07 /usr/sbin/apach
    697 mysql     20   0 4562156 177980   3884 S   0.7   0.5  23:51.15 mariadbd

Ich habe dem Server vor einigen Tagen einmal erheblich mehr RAM (32GB) und SWAP (100GB) gegeben, damit Nagios die Change hat noch Statistiken zu erfassen, bevor der OOM Killer alles beendet:

nagios.png

Ein "kill -9 ..." hilft nicht, es werden sofort Folgeprozesse gestartet, erst ein "systemctl restart apache2" beendet alles. Ich habe momentan erhebliche Probleme damit, herauszufinden, was genau diese Prozesse triggert und warum die sich den gesamten Arbeitsspeicher krallen, denn die Logdateien geben nicht viel her.

Der Block für mysql in der /opt/otrs/scripts/apache2-perl-startup.pl ist auskommentiert, wie es im Post viewtopic.php?t=43876 geraten wird.

Code: Select all

# enable this if you use mysql
use DBD::mysql ();
use Kernel::System::DB::mysql;

[root]

Hallo,

also der Verbrauch ist wirklich recht hoch. Hast du mal geprüft ob in der Zeit irgendwelche Slow Queries der Datenbank auftreten? Evtl. wartet der Webserver auch nur auf die DB. Mit 32GB kann man schon 100-200 User auf einem Server gleicheitigt drauflassen.
Nächster Check: Support Paket und prüfen was alles rot markiert ist.

- Roy

[Johannes]

Hi,
evtl. trifft dich grad dieser Bug:
https://github.com/znuny/Znuny/pull/652

Der greift beim Aufruf eines Tickets mit ICS / ICAL Dateien und löst ein Memory Leak aus.
Du kannst Du die Datei anpassen - der Fix ist oben verlinkt.

Gruß
Hannes

[khaed]

Hallo,

danke für die Antorten.

• Ich habe den Fix für den ICS Bug eingespielt. Vermutlich ist dies aber nicht der Auslöser, da eine Suche mit anschließendem Öffnen aller Tickets mit *.ics Anhängen nicht zu dem beschriebenen Effekt geführt hat, auch wenn sich das System erstaunlicherweise vorübergehend 3GB Arbeitsspeicher zusätzlich einverleibt hat.

• Bezüglich der Supportdaten-Analyse, bzw. dem AdminSupportDataCollector, was vermutlich mit "Support Paket und prüfen was alles rot markiert ist" gemeint ist, kann ich sagen das es keine rot markierten Bereiche gibt.

• Ich habe auf der Datenbank ein Slow Query Log eingerichtet, welches heute auch schon einige Einträge enthält. Momentan handelt es sich dabei um Abfragen der Volltextsuche die bis zu 7s beansprucht haben. Ich konnte die Zeit durch 10 gleichzeitige Volltextsuchen noch auf 16s hochtreiben, was neben der verlängerten zeit jedoch keine weiteren Auswirkungen hatte, CPU Load und auch RAM Last haben sich nur minimal geändert.
  Bis jetzt ist noch kein weiteres Ereignis eingetreten, was letztlich in dem Triggern des OOM Killers mündet, ich werde die Slow Query Log noch einmal erneut durchsuchen, wenn dies eintritt.

In der Zwischenzeit habe ich die /lib/systemd/system/apache2.service geändert und folgende Zeilen angefügt, damit der Apache startet, wenn der OOM Killer vorbeischauen sollte, denn der kommt natürlich besonders gerne und killt den Webserver, wenn ich bereits Feierabend habe.

Code: Select all

Restart=always
RestartSec=5

Ich melde mich noch einmal erneut, wenn ich weitere Erkenntnisse gewonnen habe.
Vielen Dank für die Unterstützung.