Performance-Probleme

[mrbrummel]

Guten Morgen,

Seit dem Update auf die Rev 29 habe ich wieder enorme Performance-Probleme auf dem Mailserver. Die Last geht vor allem immer dann in die Höhe, wenn ein Client eine Erstsynchronisierung nach der Oxtender 2 Umstellung macht. (Extrem auffällig ist es vor allem dann, wenn Sync-Probleme auftreten)

Während dieser Zeit ist bei allen Clients mit Outlook und Oxtender2 sogar die Tastatureingabe verzögert.
Tippen, einige Sekunden warten und der Text erscheint.
Der Java-Prozess nimmt die gesamte Leistung des Servers für sich.

Zur Zeit setze ich die aktuelle Version und ca 30 Clients Oxtender 2 und ca. 100 Clients "alter" Oxtender ein.

Kennt jemand diesen Effekt oder kann mann irgend etwas einstellen, damit nicht einzelne Clients den ganzen Server herunterziehen?

[Martin Heiland]

Hallo,

generell nimmt die Erstsynchronisierung einige Ressourcen in Anspruch. Je nach dem wie leistungsfähig der Client ist kann es dort natürlich auch zu Ressourcenproblemen kommen. Hast du nähere Details zu den Spezifikationen von Client und Server um das ungefähr einschätzen zu können? Vor der Rev29 gab haben wir ebenfalls eine recht aufwändige Erstsynchronisierung vorgenommen, trat das dort garantiert nicht auf? Was genau steht unter Last, der Mail (IMAP) Server, OX, Datenbank, Webserver...?

Gruß

[Marcus Klein]

Hallo MrBrummel,

wenn tatsächlich ausschließlich der Java-Prozeß die hohe CPU-Last verursacht, dann würde es uns sehr viel weiterhelfen, wenn wir wissen was gerade darin vorgeht. Diese Information bekommt man, indem man

kill -QUIT <pid>

an den Java-Prozeß sendet. Die Information über die internen Abläufe wird dann nach /var/log/open-xchange/open-xchange-console.log geschrieben. Dieses dann einfach als Attachment hier mal anhängen.

Danke

[mrbrummel]

Hallo Martin,

ich habe mal die "Lastkurve" mit eingefügt.
Interessant war für mich Juli. August Anfang September. Da lief der Server richtig gut und es gab kaum Probleme. Im September habe ich das Update auf die 29 eingespielt, und danach ging die Kurve wieder ständig nach oben.
Der Server ist ein 2Prozessor Xenon 1.6 GHz mit 8 GB RAM und die Clients sind alle mit Win7 oder XP, mindestens 2GB Ram und über 2 GHz.

Der höchste Prozess ist immer JAVA. IMAP nimmt auch mal bist 25% aber mehr nicht
Die Last ist zur Zeit immer an um die 100%. Das Problem bei der Erstsynchronisation tritt immer dann extrem auf, wenn ein Client irgendwelche Sync-Problem hat. z.B. alte Mails, die das MessageSizeLimit überschreiten (weil die Begrenzung erst später eingeführt wurde und es da beim IMAP-Zugriff keine Probleme gab) oder Kontakte mit "falschen" Enterzeichen im Dateinamen.
Doch selbst im Normalbetrieb ist das System fast immer an der Lastgrenze. Die Userzahl hat sich seit Mai auch nicht groß verändert, nur ca. 10 User habe ich von Oxtender auf Oxtender 2 umgestellt.

Bildschirmfoto am 2011-10-25 09:10:52.png

[mrbrummel]

Hier noch die Log-Datei:

open-xchange-console.log.zip

[Marcus Klein]

Ich sehe mehrere Punkte, an denen sich die Performance leicht verbessern lässt:

Auf den IMAP wird über eine verschlüsselte Verbindung zugegriffen. Ja, das funktioniert grundsätzlich, macht aber wenig Sinn, wenn der IMAP-Server auf der gleichen Maschine oder in einem gesicherten Netzwerk nahe beim OX steht. Die Verschlüsselung der Verbindung macht die Zugriffe auf den IMAP langsamer und verbraucht CPU.

Mit wieviel Heap-Memory betreibst Du den OX? Das ist in /opt/open-xchange/etc/groupware/ox-scriptconf.sh konfiguriert. Evtl. solltest Du darüber nachdenken dem Java-Prozeß mehr Speicher zu geben. Die aktuell laufenden Prozesse im OX deuten sehr darauf hin, dass der Heap recht knapp bemessen ist. Achte aber bitte darauf, dass die Maschine niemals anfängt den Auslagerungsspeicher zu nutzen. Sobald ein Java-Prozeß auch nur ansatzweise auf dem Auslagerungsspeicher landet, ist er so grausam langsam, dass man nicht mehr damit arbeiten kann.

Berichte mal bitte, ob die Änderungen einen deutlichen Performance-Gewinn bringen.

[mrbrummel]

Hier ist mal mein Inhalt der Datei.
Welche Werte soll ich ändern und was ist sinvoll? Die RAM-Nutzung des Servers liegt bei ca. 25% bis 40%.

Wo kann ich die Verschlüsselung abschalten? Der OX und Cyrus laufen auf der selben Maschine.


PROPERTIESDIR=/opt/open-xchange/etc/groupware
LOGGINGPROPERTIES=/opt/open-xchange/etc/groupware/file-logging.properties
OSGIPATH=/opt/open-xchange/etc/groupware/osgi

# This properties sets the java options given to the groupware on start
JAVA_XTRAOPTS="-Xms512m -Xmx512m -XX:+UseConcMarkSweepGC -XX:NewSize=256m -XX:MaxNewSize=256m -XX:SurvivorRatio=6 -Dsun.net.inetaddr.ttl=3600 -Dnetworkaddress.cache.ttl=3600 -Dnetworkaddress.cache.negative.ttl=10 -XX:MaxPermSize=128M"

# Maximum number of open Files for the groupware
NRFILES="8192"
# Specify the umask of file permissions to be created by ox, e.g. in the
# filestore.
# BEWARE: setting a nonsense value like 666 will make open-xchange stop working!
# useful values are 006 or 066
UMASK=066
COMMONPROPERTIESDIR=/opt/open-xchange/etc/common

[mrbrummel]

Guten Morgen,

ich habe mir mal die Datei ox-scriptconf.sh angesehen und mit einer von einem neu installierten System verglichen. Da waren einige Unterschiede:

Die von meinem Server
JAVA_XTRAOPTS="-Xms512m -Xmx512m -XX:+UseConcMarkSweepGC -XX:NewSize=256m -XX:MaxNewSize=256m -XX:SurvivorRatio=6 -Dsun.net.inetaddr.ttl=3600 -Dnetworkaddress.cache.ttl=3600 -Dnetworkaddress.cache.negative.ttl=10 -XX:MaxPermSize=128M"

und von einem neuen System:
JAVA_XTRAOPTS="-Xmx512m -XX:+UseConcMarkSweepGC -XX:MaxPermSize=128M -Dsun.net.inetaddr.ttl=3600 -Dnetworkaddress.cache.ttl=3600 -Dnetworkaddress.cache.negative.ttl=10"

Nachdem ich die "kurze und neue" Version übernommen habe, ging bei gleiche Speicherwerten die Last auf die Hälfte zurück.

Die ox-scriptconf.sh wurde Anfang März (mit einigen anderen Dateien) neu erstellt.

Gordon

[Martin Heiland]

Hallo,

diese Datei wird hin und wieder mit optimierten Werten aktualisiert. Der Paketmanager legt vermutlich eine .dpkg-new Datei an um die alte nicht zu überschrieben. Relevant für dich ist vor allem der -Xmx Wert, das ist der Speicher den sich OX maximal unter den Nagel reißen darf. Wenn du also viel freien Speicher hast, kann es nicht schaden diesen wert etwas hochzusetzen. Jedoch nicht zu hoch, denn sonst kann die JVM abstürzen.

Gruß

[mrbrummel]

Ich habe den Wert mal auf 1024 gesetzt und werde heute Abend den wert mal noch etwas erhöhen, da ich ständig immer noch über 4 GB freien Speicher habe.

Die Lastkurve spricht für sich.
ucs_0load-day.png

Danke für den Hinweis.

Gordon

[Markus Wagner]

Ich habe für das Problem mit den alten Werten einen Bug aufgemacht. Hier wurde definitiv bei einem Update die alte Konfiguration beibehalten und nicht durch unsere neuen, angepassten Werte ersetzt.