Diverse HTTP Fehlermeldungen

[lekev]

Hallo zusammen,

das die OTRS Performance bei uns etwas lahm ist, ist leider nichts neues. Ich habe die Serverlast bei einem Seitenaufruf mal beobachtet und dabei ist mir aufgefallen, dass ein httpd Prozess dann immer ca 3-4sek bei 100% Auslastung ist, bis die Seite fertig geladen scheint.

Ein Blick in die Logs zeigt u.a. folgende Fehler:

1)

Code: Select all

[Wed Jun 24 09:11:16 2020] -e: Argument "2020-06-23..." isn't numeric in numeric ge (>=) at /opt/otrs//Kernel/Output/HTML/Layout.pm line 2155.
[Wed Jun 24 09:11:16 2020] -e: Argument "2020-06-22..." isn't numeric in numeric ge (>=) at /opt/otrs//Kernel/Output/HTML/Layout.pm line 2155.
[Wed Jun 24 09:11:16 2020] -e: Argument "2020-06-23..." isn't numeric in numeric ge (>=) at /opt/otrs//Kernel/Output/HTML/Layout.pm line 2155.
[Wed Jun 24 09:11:16 2020] -e: Argument "2020-06-24..." isn't numeric in numeric ge (>=) at /opt/otrs//Kernel/Output/HTML/Layout.pm line 2155.
[Wed Jun 24 09:11:16 2020] -e: Argument "2020-06-23..." isn't numeric in numeric ge (>=) at /opt/otrs//Kernel/Output/HTML/Layout.pm line 2155.

--> ~ 30 Logeinträge pro Sekunde mit der gleichen Meldung. Bei jedem Seitenaufruf.

Die betreffende Zeile in der Layout.pm sieht wie folgt aus:

Code: Select all

    # get days
    if ( $Age >= 86400 ) {
        $AgeStrg .= int( ( $Age / 3600 ) / 24 ) . ' ';
        $AgeStrg .= $Self->{LanguageObject}->Translate($DayDsc);
        $AgeStrg .= $Space;
    }

Sieht für mich auf den ersten Blick ok aus.

Ein anderer Fehler, der genauso häufig erscheint:

Code: Select all

[Wed Jun 24 09:13:02 2020] -e: Argument "Europe/Berlin" isn't numeric in multiplication (*) at /opt/otrs//Kernel/Modules/AgentTimeAccountingOverview.pm line 191.
[Wed Jun 24 09:13:02 2020] -e: Argument "Europe/Berlin" isn't numeric in multiplication (*) at /opt/otrs//Kernel/Modules/AgentTimeAccountingOverview.pm line 191.
[Wed Jun 24 09:13:02 2020] -e: Argument "Europe/Berlin" isn't numeric in multiplication (*) at /opt/otrs//Kernel/Modules/AgentTimeAccountingOverview.pm line 191.
[Wed Jun 24 09:13:02 2020] -e: Argument "Europe/Berlin" isn't numeric in multiplication (*) at /opt/otrs//Kernel/Modules/AgentTimeAccountingOverview.pm line 191.
[Wed Jun 24 09:13:02 2020] -e: Argument "Europe/Berlin" isn't numeric in multiplication (*) at /opt/otrs//Kernel/Modules/AgentTimeAccountingOverview.pm line 191.

Auch in dem Fall wurde die AgentTimeAccountingOverview.pm nicht verändert/angepasst.

Und ein zusätzlicher Fehler, der nicht ganz so oft erscheint:

Code: Select all

[Wed Jun 24 09:14:14 2020] -e: Can't locate package Kernel::System::Ticket::Custom for @Kernel::System::Ticket::ISA at /opt/otrs//Kernel/System/ObjectManager.pm line 580.

Sieht für mich alles ingesamt nach einem Datum/Zeitzonen Problem aus.

Hat jemand eine Idee, wie man die Fehler lösen kann? Die Uhrzeit an sich stimmt auf dem Server

Die Logeinträge stammen übrigens alle aus /var/log/httpd/error_log. Unter /opt/otrs/var/log.. ist kaum ein Fehler drin.

Viele Grüße
Kevin

[zzz]

Hallo Kevin,

habt ihr ganz allgemein irgendwelche Änderungen am Code vorgenommen?
Die Meldungen sehen relativ spezifisch aus.

Zudem würde ich ein Update auf die neuste Version empfehlen, wenn die Versions-Info korrekt ist.

Viele Grüße
Emin

[lekev]

Hallo Emin,

nein am Code der Datei selbst nichts, die entspricht noch dem Ursprungszustand aus dem rpm Paket. Im Adminbereich könnte möglicherweise etwas verändert worden sein, aber auf dem ersten Blick habe ich da keine Änderung festgestellt.. ich wüsste gar nicht wo man die Layout.pm ändern kann.

Im Einsatz ist aktuell die v 6.0.28

Viele Grüße
Kevin

[zzz]

In dem Fall kann die letzte Meldung natürlich auch von einem (alten) externen Paket kommen.
Nach einem Apache restart sollte die Meldung nicht mehr erscheinen, wenn es keine Fehlerhaft konfigurierte XML gibt.

Die zweite Meldung ist ein Fehler im TimeAccouting Modul.
Um das Paket würde ich allgemein einen großen Bogen machen, da es über die Jahre relativ Stiefmütterlich behandelt wurde.
Die Zeitzonen für die einzelnen Kalendar müssten unter "TimeZone::Calendar" deaktiviert werden, damit der Fehler zumindest verschwindet.

Bei der ersten Meldung bin ich mir jedoch nicht sicher, da die Subroutine standardmäßig eine Zeitangabe in Sekunden erwartet.
Könnte auch an einer verbuggten Einstellung liegen, aber da müsste man tatsächlich etwas debuggen.

Es ist gut möglich, dass die schlechte Performance an den Fehlern liegt, da ich 3–4 Sekunden pro Aufruf schon für extrem langsam halte.

Viele Grüße
Emin