Hauptmenü

Performance Ratgeber

Begonnen von Fabian Seibt, 12.09.2017 13:49:01

⏪ vorheriges - nächstes ⏩

Fabian Seibt

Hallo zusammen,

die Ursachen für Performanceprobleme mit KIX können vielfältig sein.

Der erste Ansatz für eine Behebung dessen, kann die Analyse der Prozessliste mit den Tools top/htop sein.
An dieser Stelle sieht man auf den ersten Blick, ob die CPU-Kerne oder der RAM ausgelastet sind bzw. ob evtl. "festhängende" Prozesse existieren (Apache2, MySQL, PostgreSQL, ...).
Für den Fall, dass hängende Prozesse für das Performanceproblem zuständig sind, reicht es zur kurzfristigen Behebung meist schon betroffene Dienste neu zu starten.

Sollte der Fehler wiederholt auftreten, so muss die nähere Analyse fortgesetzt werden. Dazu sollten folgende Fragen genauer betrachtet werden:

1. Ist das System generell langsam oder lässt es sich auf bestimmte Masken eingrenzen?
          Sollte es sich bei dem Problem um eine bestimmte Maske handeln, kann das Aktivieren des Performancelogs helfen diese einzugrenzen.
          Es kann außerdem noch auftreten, das der Aufruf eines bestimmten Tickets sehr langsam ist, weil sich in diesem Ticket eine große Menge an Artikeln befindet, oder ein Artikel sehr viele Zeilen enthält.

2. Verwenden Sie einen Proxy?
          Wird ein System lokal getestet und im Anschluss in eine Serverlandschaft übernommen, in welcher sich ein Proxy für den Zugriff befindet, wird der Zugriff über den Proxy länger dauern als lokal.
          Hier ist eine Optimierung der Serverressourcen nicht zielführend.

3. Ist die Hardware/Virtualisierung optimal konfiguriert? Sind andere virtuelle Maschinen meiner Umgebung betroffen?
          Sobald eine virtualisierte Umgebung verwendet wird und der Fehler in anderen Systemen ebenfalls auftritt, kann z.B. das Storage System dafür verantwortlich sein.

4. Wie viele Agenten arbeiten konkurrierend mit dem System? Handelt es sich um eine Systemspitze?
          Eine morgendliche Lastspitze sollte kein Grund für eine Änderung des Systems sein. Diese kann zum Beispiel hervorgerufen werden sobald sich alle Agenten fast zeitgleich anmelden.

5. Habe ich lokale Verbindungen oder Remoteverbindungen? (LDAP, Datenbank, etc..)

          Natürlich kann auch eine schlechte/langsame Verbindung in Ihrem Systemumfeld der Grund für die Probleme sein.
          Weiterhin ist zu prüfen, ob evtl. mehrere Kundendatenbackends angebunden sind, wie gut deren Anbindung ist und wie die CacheTTL konfiguriert ist.

6. Wird die CMDB genutzt? Wenn ja, wie viele CI's sind im System vorhanden?
          Bei Verwendung von KIX Base wird der Zugriff auf die CMDB, mit zunehmender Anzahl der CI's, langsamer.
          Dies ist der Art der Speicherung in der Datenbank geschuldet und kann durch ein Upgrade auf KIX Pro behoben werden.

7. Wie viele Tickets, Artikel und Anhänge habe ich aktuell in meinem System?

          Bei steigender Anzahl von Tickets, Artikeln oder großer Anhänge steigt natürlich die Belastung des Systems. An dieser Stelle muss entsprechend nachgesteuert werden.

8. Welches Filesystem wird eingesetzt? Welcher IO-Scheduler wird verwendet? Werden die Artikeldaten auf dem Filesystem gespeichert?
          Unter Umständen kann die Performance des Storagesystems oder der HDD ausgereizt sein. Die Performance kann z.B. mit dem Tool iostat gemessen und analysiert werden.
          In ganz extremen Fällen gibt das Fehlerlog des Apache2 Webservers auch einen Hinweis darauf.

9. Wie ist das Mailing konfiguriert? (Abholung, Versand, Anbindung)
          Der Postmaster Maildienst hat z.B. Probleme sobald eine sehr große oder fehlerhafte Mail abgeholt wird. Diese kann dazu führen, dass der Prozess hängen bleibt.
          Wird nun ein neuer Prozess gestartet, obwohl der alte noch nicht beendet ist, kann dies ein performantes System an den Rand seiner Möglichkeiten treiben.
          Sollte dieser Fehler öfter auftreten, kann die Mailumstellung von Postmaster auf Fetchmail eine Lösung des Problems sein.

10. Wird der Swap in meinem System verwendet?
          Sobald ein Linuxsystem regelmäßig anfängt zu swappen, reicht der Arbeitsspeicher für den täglichen Gebrauch nicht aus. Hier muss am RAM nachgesteuert werden.

11. Befindet sich die Datenbank auf dem gleichen Server wie die Applikation?
          Bei einem Performanceproblem mit einer lokalen Datenbank ist es wichtig den RAM ausreichend zu dimensionieren.
          Sollte die Performance des Speichers ausgereizt sein, kann es von Vorteil sein die Datenbank auf einen separaten Server auszulagern.

Ein kleiner Tipp zum Abschluss:
Nicht immer gilt der Grundsatz ,,viel hilft viel"! Wenn Sie dem System z.B. sehr viel RAM zur Verfügung stellen, muss sichergestellt sein, dass dieser auch genutzt wird. (z.B. DBMS und KIX müssen entsprechend konfiguriert werden)
Best-Practise-Ansatz: so klein wie möglich starten, Kennzahlen beobachten und Ressourcen in kleinen, sinnvollen Schritten erhöhen!

VG Fabian