-
Posts
-
-
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
-
-
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.
-
-
-
-
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 = 256Mlog_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100Mcharacter-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] -
Hallo Leute,
wir haben immer mal wieder das Problem, dass manche Tickets echt lange zum öffnen brauchen.
Es wird dann gesagt:
- „Hat ja auch viele Anhänge“ oder
- „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?
-
-
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.
-
-
- You must be logged in to reply to this topic.