[Obm] OPUSH/jetty dans la version 2.4.0.1

[Matthieu Baechler]

Bonjour,

Nous avons des problèmes connus concernant l'utilisation excessive de
mémoire dans opush.

Le problème se produit principalement lors de l'initialisation des
périphériques mobiles puisque ceux-ci synchronisent le maximum de
données à ce moment précis.

Nous travaillons sur ce problème depuis maintenant 2 mois et des
évolutions importantes sont à venir sur la version 2.4.2.

En attendant, pour minimiser le problème, vous pouvez :

- allouer plusieurs Go de RAM à jetty (dans /etc/default/jetty)
- configurer vos smartphones pour synchroniser seulement 3 jours de
mails
- faire une mise en route progressive de vos smartphone de manière à
sérialiser la synchronisation initiale de chaque périphérique

Cordialement,

-- 
Matthieu Baechler

Le jeudi 12 avril 2012 à 17:20 +0200, Couturie Laure-Amélie a écrit :
> Bonjour,
> 
> Nous venons de faire l'upgrade de notre serveur obm en version 2.4.0.1. 
> Il est en exploitation depuis aout 2010 en version 2.3.12 avec environ 
> 450 utilisateurs satisfaits de ce service.
> Tout s'est plutôt bien passé, nous en avons profité pour installer 
> Roundcube qui fonctionne bien.
> 
> Nous rencontrons un problème de mémoire avec  opush via jetty et le 
> process java jsvc.
> Nous avons augmenté la taille de ce process à 4GO avec l'argument 
> -Xmx4096m (le défaut était de 512m):
> # ps -ef|grep jsvc
> root       930 25026  0 17:03 pts/1    00:00:00 grep jsvc
> root     25007     1  0 15:48 ?        00:00:00 /usr/bin/jsvc -user 
> jetty -cp 
> /usr/share/java/commons-daemon.jar:/usr/share/jetty/start.jar:/usr/share/jetty/start-daemon.jar:/usr/lib/jvm/java-6-sun/lib/tools.jar 
> -outfile /var/log/jetty/out.log -errfile /var/log/jetty/out.log -pidfile 
> /var/run/jetty.pid -Xmx4096m -Djava.awt.headless=true 
> -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/var/cache/jetty/data 
> -Djava.library.path=/usr/lib -DSTART=/etc/jetty/start.config 
> -Djetty.home=/usr/share/jetty -Djetty.logs=/var/log/jetty 
> -Djetty.host=0.0.0.0 -Djetty.port=8082 
> org.mortbay.jetty.start.daemon.Bootstrap /etc/jetty/jetty-logging.xml 
> /etc/jetty/jetty.xml /etc/jetty/jetty-shared-webapps.xml
> jetty    25008 25007 99 15:48 ?        02:01:20 /usr/bin/jsvc -user 
> jetty -cp 
> /usr/share/java/commons-daemon.jar:/usr/share/jetty/start.jar:/usr/share/jetty/start-daemon.jar:/usr/lib/jvm/java-6-sun/lib/tools.jar 
> -outfile /var/log/jetty/out.log -errfile /var/log/jetty/out.log -pidfile 
> /var/run/jetty.pid -Xmx4096m -Djava.awt.headless=true 
> -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/var/cache/jetty/data 
> -Djava.library.path=/usr/lib -DSTART=/etc/jetty/start.config 
> -Djetty.home=/usr/share/jetty -Djetty.logs=/var/log/jetty 
> -Djetty.host=0.0.0.0 -Djetty.port=8082 
> org.mortbay.jetty.start.daemon.Bootstrap /etc/jetty/jetty-logging.xml 
> /etc/jetty/jetty.xml /etc/jetty/jetty-shared-webapps.xml
> 
> En surveillant le démon par top, on voit sa taille mémoire augmenter et 
> le service finit par se planter sur des erreurs de type (opush.log):
> 17:21:21.921 [ERROR] {o.o.a.t.TransactionalInterceptor} 
> [t/c/r/]:transaction was rollback
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 17:21:22.005 [ERROR] {o.o.a.t.TransactionalInterceptor} [t/c/r/]:GC 
> overhead limit exceeded
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 
> Quelqu'un a t il rencontré le même problème? A t on un problème de 
> paramétrage? (nous avons environ 70 périphériques mobiles déclarés)
> 
> Merci d'avance. Cordialement.
>