[Andreas Brandts]

Hi Leute,

 

ich hab ein Ticket, welches echt lange läd, bevor es angezeigt wird.

Der Ootobo Job geht dann auch auf 100% CPU leistung. Das hatte ich mit “top” auf Shell-Ebene gesehen. Bild im Anhang.

Es gibt für mich keinen offensichtlichen Grund, warum das Ticket so lange läd.

– Keine Sonderzeichen im Emailverlauf gesehen

– Keine großen anhänge >10MB o.ä.

– Systemprotokoll zeigt keine Fehler diesbezüglich

Tja,

ich habe keinen Ansatz zum Debuggen.

Hat da jemand eine Idee oder Fragen?

 

LG

 

[marcel-graf]

Hallo Andreas,

tritt das Problem mit allen gängigen Browsern auf?

Wir haben auch machmal Tickets, die gefühlt länger dauern, ehe diese öffnen.

Gruß Marcel

[Andreas Brandts]

Moin Marcel,

 

ja, das Problem tritt mit allen Browsen auf. Ich habe Firefox und Chrome getestet.

Manchmal “verlangsamt Firefox ja eine Seite”, allerdings sehe ich hier nicht das Problem im Browser,  weil der otobo.Console.pl auf 100% CPU leistung geht und zudem im gleichen Browser, indem das Ticket lange läd, andere Tickets schnell laden.

 

Es muss was mit der Datenbank zu tun haben. Ich erinnere mich daran, dass Emojies die Datenbank damals kaputt gemacht haben, worauf hin dies korrigiert worden ist. Bauchgefühl sagt mir, dass das es was damit zu tun haben könnte, weil ich kurz vor auftreten dieses Tickets, welches lange läd, ein Testticket mit einem Emojie erstellt hatte, um zu sehen, was das Otobo 10.1.4. bzw die MariaDB macht.

 

[Stefan Rother]

Guten Morgen,

sind alle Tabellen und Spalten sicher uft8mb4 und passt auch die Collation? Wenn da irgendwo Latin, utf8 oder utf8mb3 eingestellt ist, dann wäre das der Ansatz,

Schöne Grüße,

Stefan

[Andreas Brandts]

Ah, gute Idee.. prüfe ich.

Wobei, Otobo hat bei der Installation die Tabele angelet…

 

prüfe ich einmal.

[Andreas Brandts]

Geprüft und sieht meines Erachtens gut aus:

 

hier der Screenshot

[Andreas Brandts]

Das Problem weitet sich ein wenig aus. Ansichten laden lange aber manchen Ansichten, wie z.B. die Übersicht geth dann wieder fix.

Teilweise dauert es bis zu einigen Minuten, bis ein Ticket geladen ist.

Es muss die Datenbank sein. Vielleicht sieht jemand etwas Affälliges in meiner Config?

Auszug aus meiner: /etc/mysql/mariadb.conf.d/50-server.cnf

# this is read by the standalone daemon and embedded servers
[server]

# this is only for the mysqld standalone daemon
[mysqld]

#
# * Basic Settings
#

user = mysql
pid-file = /run/mysqld/mysqld.pid
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
#lc-messages = en_US
lc-messages = de_DE
skip-external-locking
userstat = 1
tmp_table_size=64M
max_heap_table_size=64M

<h6>#
performance_schema=ON
performance-schema-instrument=’stage/%=ON’
performance-schema-consumer-events-stages-current=ON
performance-schema-consumer-events-stages-history=ON
performance-schema-consumer-events-stages-history-long=ON
query_cache_size = 512M
#######</h6>
# Broken reverse DNS slows down connections considerably and name resolve is
# safe to skip if there are no “host by domain name” access grants
skip-name-resolve

# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address = 127.0.0.1

#
# * Fine Tuning
#

#key_buffer_size = 128M
max_allowed_packet = 64MB
innodb_log_file_size = 256M

log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M

character-set-server = utf8mb4
collation-server = utf8mb4_general_ci

# this is only for embedded server
[embedded]

# This group is only read by MariaDB servers, not by MySQL.
# If you use the same .cnf file for MySQL and MariaDB,
# you can put MariaDB-only options here
[mariadb]

# This group is only read by MariaDB-10.5 servers.
# If you use the same .cnf file for MariaDB of different versions,
# use this group for options that older servers don’t understand
[mariadb-10.5]

 

[Andreas Brandts]

Hallo Leute,

 

wir haben immer mal wieder das Problem, dass manche Tickets echt lange zum öffnen brauchen.

 

Es wird dann gesagt:

 

1. “Hat ja auch viele Anhänge” oder
2. “Es hat ja auch viel Artikel”

 

Es jat irgendwas ggf. mit den Artikeln zu tun.

ich habe im Otobo die Artikel auf “FS” gesetzt und nicht DB.

Was kann man hier machen?

 

 

[Man Cheung Ip]

Hi,

wenn es die DB ist, dann schau mal nach “slow query log”. Wie reagiert denn MariaDB wenn du dich manuell auf die Datenbank einloggst? Ich habe z. B. bei innodb_log_file_size = 1G und innodb_buffer_pool_size = 4G drin, dafür hat er auch 32G RAM :D

 

Gruß

Manni

[Andreas Brandts]

Hallo Manni,

 

also, das slow query log ist bei mir deaktiviert.

Die innodb_log_file_size ist bei bei mir auf 256MB wie das normal sein sollte und innodb_buffer_pool_size ist bei mir auch auf 4 Gb, da der Server auch 32 GB RAM verfügt.

 

Edit:

Es muss an der Struktur der DB liegen. Da stimmt etwas nicht.

[Fabian Baumgartner]

Hallo Andreas

Hast du bereits eine Lösung gefunden? Ich habe ein ähnliches Problem. Plötzlich seit ein paar Wochen dauert es lange um gewisse Tickets zu öffnen, zum Antworten. Auch die Anmeldeseiten werden erst nach ca. 2 Minuten geladen.

Nur die CPU Auslastung ist bei mir unter 5%…

Gruss Fabian

[Andreas Brandts]

Hi Fabian,

nein dafür gibt es bislang keine Lösung, da die Ursache unbekannt ist.

 

VG
Andreas

[Fabian Baumgartner]

Hallo Andreas

Bei mir hing das Problem mit LDAPS zusammen. Als ich LDAPS in der Konfiguration entfernte und die Benutzer:innen lokal anlegte, war das Problem bei mir behoben.

Gruss Fabian

[Andreas Brandts]

Ah ! Da war was!!!
Im alten OTRS5 war ein ähnliches Problem und die Lösung war dann alle Netzzwerkverbindungen (zu anderen Diensten) des OTRS zu kappen.

 

Danke

 

VG
Andreas

[Autor]

Beiträge