[SOLVED] OTRS ITSM auch bei kleinem System sehr langsam

[christian82]

Hallo zusammen,

wir haben ein SEHR kleines OTRS ITSM am Laufen. Es sind ca. 15 Agenten, wobei maximal drei gleichzeitig eingeloggt sind. Tickets sind wir aktuell bei knapp sechzig.

Die Übersichten laden sehr schnell (auch z.B. SysConfig oder die Admin Seite), auch die Tickets wenn man eins öffnet.

Leider dauert es sehr lange bis die "Antworten" Fenster laden. Über eine Minute bis ich überhaupt eine Antwort verfassen kann. Auch das Senden selbst dauert ca. zwei Minuten. Wobei das am sendmail Deamon liegen kann.

Gleiches beim Anlegen eines neuen Tickets (egal ob Telefon oder Email). Hier laden die Dropdown Listen sehr lange. Sobald ein Feld geändert wird dauert es eine gefühlte Ewigkeit bis die anderen DropDown Listen wieder geladen sind.

Dynamische Felder sind bis auf vier keine aktiviert und ACLs gibt es (noch) nicht.

Die Tuning Optionen aus dem Handbuch habe ich schon alle eingerichtet.

Grüße,

Christian

[Hazet]

OS? DB? OTRS-Version?
Anzahl Cores? RAM?

Ein bisschen mehr Info musst schon liefern wenn Du eine Antwort willst...

[christian82]

OTRS wird bei uns auf Windows Azure gehostet.

OS: Ubuntu 14.04
DB: MySQL
OTRS ITSM 3.3.9
1 Core mit 1,75 GB RAM

[schulmann]

Was sagt "vmstat 10" oder "top" während der Wartezeit?

[christian82]

Bei Antworten:

vmstat 10:
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 239528 65828 338468 0 0 8 54 283 102 1 0 94 5 0
0 0 0 239520 65828 338500 0 0 0 1 274 70 0 0 100 0 0
0 0 0 230964 65844 338540 0 0 2 23 284 124 21 1 78 1 0
0 0 0 230956 65844 338540 0 0 0 0 276 75 0 0 100 0 0
2 0 0 230832 65844 338540 0 0 0 0 274 70 0 0 100 0 0
1 0 0 229708 65844 338540 0 0 0 0 275 73 0 0 100 0 0
0 0 0 229708 65844 338544 0 0 0 16 279 75 0 0 99 1 0
1 0 0 229708 65844 338544 0 0 0 0 273 69 0 0 100 0 0
0 0 0 229708 65844 338544 0 0 0 0 275 72 0 0 100 0 0
0 0 0 229708 65844 338544 0 0 0 2 274 69 0 0 100 0 0
0 0 0 228220 65844 338560 0 0 2 4 277 78 3 0 97 1 0
4 0 0 228220 65844 338560 0 0 0 38 277 78 0 0 97 3 0
0 0 0 228220 65844 338560 0 0 0 0 276 72 0 0 100 0 0

Bei top ist die CPU Nutzung bei unter 5%, mysqld springt bei der Memory Nutzung kurzfristig ca 1-2 Sekunden auf 19,4 % das wieder holt sich ca. 5 mal über die gesamte Dauer von ca. 1-2 Minuten.

Beim Anlegen von Tickets:
Bei top genau das gleiche wie oben.

vmstat 10 (vier Felder geändert und den Kundennutzer eingetragen):

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 223756 63836 269020 0 0 7 54 283 102 1 0 94 5 0
0 1 0 223128 63836 269064 0 0 0 202 315 210 9 1 81 9 0
3 0 0 221400 63840 269192 0 0 0 259 324 252 12 2 75 12 0
0 0 0 214084 63848 269272 0 0 0 151 297 167 8 1 85 6 0
0 0 0 214084 63848 269272 0 0 0 0 276 75 0 0 100 0 0
0 0 0 214084 63848 269272 0 0 0 0 273 71 0 0 100 0 0
0 0 0 214084 63848 269272 0 0 0 30 276 71 0 0 100 0 0
0 0 0 213712 63848 269276 0 0 0 5 277 82 0 0 98 1 0
0 0 0 213712 63848 269276 0 0 0 46 276 81 0 0 97 3 0
2 0 0 209772 63872 269252 0 0 0 57 291 132 4 1 95 1 0
0 0 0 209648 63872 269276 0 0 0 109 286 96 0 0 95 5 0
0 0 0 209648 63872 269292 0 0 0 0 273 75 0 0 100 0 0
0 0 0 209648 63872 269292 0 0 0 0 274 75 0 0 100 0 0
0 0 0 209648 63872 269292 0 0 0 0 273 73 0 0 100 0 0
0 0 0 208904 63872 269292 0 0 0 4 276 85 1 0 99 0 0
0 0 0 208904 63872 269292 0 0 0 17 274 78 0 0 99 1 0
0 0 0 207028 63876 269968 0 0 68 1 284 97 0 0 98 1 0
0 0 0 205912 63876 270160 0 0 19 49 289 125 2 0 97 1 0
0 0 0 206532 63876 270164 0 0 0 14 278 86 0 0 98 2 0
1 0 0 206532 63876 270168 0 0 0 4 279 91 0 0 100 0 0
0 0 0 204920 63936 270748 0 0 64 8 294 172 6 1 90 2 0

Interessant ist, dass die Verlangsamung erst nach dem Eintragen des Kundennutzers anfängt.

NACHTRAG: Im Kundenmenü ist Anlegen und Antworten super schnell...

[Hazet]

Naja, besonders üppig ist die VM ja nicht konfiguriert.
Wie sieht denn die mysql-Konfiguration aus? Kannst Du mal das Kommandozeilentool mysqltuner starten?
Was sagt das Support-Tool (Admin->Support-Assessment)?

[christian82]

Support Assessment zeigt alles grün an. In der MySQL config sind die Werte zum Teil extrem hoch. Das liegt aber daran, dass ich sie testweise mal hochgeschraubt habe um ausschilessen zu können, dass der Daemon zu wenig Speicher erhält.

MySQLTuner:
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.38-0ubuntu0.14.04.1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[--] Data in InnoDB tables: 53M (Tables: 151)
[!!] Total fragmented tables: 151

-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 39m 8s (7K q [3.356 qps], 107 conn, TX: 4M, RX: 1M)
[--] Reads / Writes: 86% / 14%
[--] Total buffers: 1.2G global + 2.7M per thread (151 max threads)
[!!] Maximum possible memory usage: 1.6G (96% of installed RAM)
[OK] Slow queries: 0% (0/7K)
[OK] Highest usage of available connections: 8% (13/151)
[OK] Key buffer size / total MyISAM indexes: 1.0G/100.0K
[OK] Query cache efficiency: 89.9% (6K cached / 7K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 164 sorts)
[OK] Temporary tables created on disk: 15% (56 on disk / 366 total)
[OK] Thread cache hit rate: 87% (13 created / 107 connections)
[!!] Table cache hit rate: 10% (128 open / 1K opened)
[OK] Open file limit used: 0% (0/1K)
[OK] Table locks acquired immediately: 100% (1K immediate / 1K locks)
[!!] Connections aborted: 22%
[OK] InnoDB data size / buffer pool: 53.3M/128.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Reduce your overall MySQL memory footprint for system stability
Enable the slow query log to troubleshoot bad queries
Increase table_cache gradually to avoid file descriptor limits
Your applications are not closing MySQL connections properly
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
table_cache (> 128)


MySQL config:
#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
#
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/serve ... ables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

[mysqld]
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# 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 = 1024M
max_allowed_packet = 30M
thread_stack = 192K
thread_cache_size = 80
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover = BACKUP
max_connections = 151
table_cache = 128
thread_concurrency = 100
#
# * Query Cache Configuration
#

query_cache_limit = 64M
query_cache_size = 32M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file = /var/log/mysql/mysql.log
#general_log = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#log_slow_queries = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
# other settings you may need to change.
#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer = 16M

#
# * IMPORTANT: Additional settings that can override those from this file!
# The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

[Hazet]

Mein Vorschlag wäre, erst mal die mysql auf vernünftigere Werte zu setzen (wo hast Denn die Werte her? Du fährst hier ziemliches Risiko...)

Code: Select all

key_buffer=64M
thread_stack=1024K
thread_cache_size=16
max_connections = 150 # Oder auch weniger
table_cache=512
thread_concurrency auskommentieren
query_cache_limit=16M
query_cache_size=64M


innodb_buffer_pool_size=400M

Der RAM-Verbrauch von Deiner DB ist m.E. nach zu hoch was das System zum auslagern zwingt. Wie voll ist denn Swap?
Ach ja: Nach der Änderung mysql neu starten und den mysqltuner nach frühestens 24h noch mal drüber laufen lassen...

[christian82]

Swap file ist leer, also unbenutzt.
EDIT: Gerade nochmal geschaut 200 MB swap ist voll!

Ich ändere jetzt erstmal die Einstellungen auf die vorgeschlagenen und schau ob sich da was tut.

[Hazet]

Ich nehme halt mit meiner config an, daß Du (wie standardmässig vorgesehen) innodb nutzt. Ansonsten wäre meine Konfig Mist und Deine besser...

[christian82]

also... Config angepasst, DB neugestartet, nicht besser aber auch nicht schlechter

[christian82]

OK, spaßeshalber mal die VM Config erhöht: 2 Kerne und 3,5 GB RAM.

Leider das gleiche Spiel....

[mfuhrmann]

Hey!

Ich habe ein ähnliches Phänomen was die Ladezeiten angeht. Bisher habe ich nur herausgefunden, dass es irgendwie mit dem httpd zu tun haben muss. Wird dieser neugestartet, geht es wieder um einiges schneller. Und das kommt alle paar Tage.

Gruß
Marcel

[jojo]

bitte auch mal die Festplattengeschwindigkeit testen (hdperf). Wie werden emails aus dem OTRS versendet?

[schulmann]

Zur Sicherheit würde ich den HTTP-Server überprüfen: viewtopic.php?f=35&t=23333

[christian82]

Ich habe mal die Änderungen an der Apache Config vorgenommen. Leider kein Erfolg. Auch das Neustarten von Apache2 bringt keinen Erfolg.

Mysqltuner auch nochmal laufen lassen. Er meldet zwar, dass 151 Tables fragmentiert sind und ich mysqlcheck laufen lassen soll. Starte ich mysqlcheck mit -o --alltables erhalte ich für alle OTRS Tables die Meldung "Table does not support optimize, doing recreate + analyze instead".

Mysqltuner meldet dann aber wieder 151 Tables als fragmentiert.

Was ich komisch finde ist, dass die Dropdown Felder erst nach dem Hinzufügen des Kunden so langsam werden. Davor dauert es 1-2 Sekunden bis alle Felder aktualisiert sind.

[schulmann]

Als nächstes würde ich mir die DNS-Anfragen ansehen, z. B. so: tcpdump -n -i any 'port 53'

[christian82]

HALLELUJA!!!!

Das war der Schubs in die richtige Richtung! Ich hatte das Azure Netzwerk mal über VPN an unser lokales Netzwerk angeschlossen und unsere eigenen DNS Server eingetragen. Da diese VPN Verbindung nicht mehr steht (bzw. dauerhaft aktiv ist), hat der Server immer die falschen Server kontaktiert.

"Falsche" DNS Server gelöscht, neu gestartet und es funktioniert so wie ich es mir vorgestellt habe!

DANKE DANKE DANKE!!!!

[wurzel]

Hi,

achja... das schöne alte DNS


schön dass es läuft. Sieht man mal, wie wichtig schnelle + korrekte DNS Auflösung ist (nicht nur bei OTRS)



Flo