Bonjour,
J’ai 6Go de ram utilisés sur 8.
Que puis-je vous remonter comme logs pour identifier le problème, pur l’instant je ne reboote pas 
Sacha.
PS: ci-dessous un tri des process par leur taille mémoire
Salut je ne sais pas si cela t’aidera mais voici l’état de mon serveur avec 6Go de mémoire :
sachant que j’ai ajouté à la configuration de base un antivirus et un antispam, que mon déploiement d’utilisateurs est encore limité, pas plus de 10 sur pplus de 200, et le serveur en sous-utilisation pour le moment. moins de 10 à 15 échanges d emails par jours.
[quote]# ps -eo pmem,pcpu,rss,vsize,args | sort -k 1 -r | head -n 11
%MEM %CPU RSS VSZ COMMAND
5.7 0.4 344460 1703716 /usr/lib/jvm/java-openjdk/bin/java -server -Xms256m -Xmx256m -XX:MaxPermSize=128m -Xss1m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -Djava.security.egd=file:/dev/./urandom -cp /usr/share/bm-mq/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar org.eclipse.equinox.launcher.Main -application net.bluemind.hornetq.mqsrv
4.0 0.1 246072 416424 clamd.amavisd -c /etc/clamd.d/amavisd.conf --pid /var/run/amavisd/clamd.pid
3.3 0.1 201564 1675348 /usr/lib/jvm/java-openjdk/bin/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Dfile.encoding=UTF-8 -Xms256m -Xmx256m -XX:MaxPermSize=128m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.awt.headless=true -Duser.timezone=GMT -Djava.endorsed.dirs=/usr/share/tomcat/endorsed -classpath :/usr/share/tomcat/bin/bootstrap.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.io.tmpdir=/tmp org.apache.catalina.startup.Bootstrap start
3.2 0.1 193376 1704200 /usr/lib/jvm/java-openjdk/bin/java -Xrs -server -Xms256m -Xmx256m -XX:MaxPermSize=128m -Xss1m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -Djava.security.egd=file:/dev/./urandom -cp /usr/share/bm-core/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar org.eclipse.equinox.launcher.Main -application net.bluemind.core.launcher.core
2.5 0.2 156148 1547312 /usr/lib/jvm/java-openjdk/bin/java -server -Xms128m -Xmx128m -XX:MaxPermSize=128m -Xss1m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -Djava.security.egd=file:/dev/./urandom -cp /usr/share/bm-eas/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar org.eclipse.equinox.launcher.Main -application net.bluemind.eas.push
2.2 0.1 135972 1543768 /usr/lib/jvm/java-openjdk/bin/java -server -Xms128m -Xmx128m -XX:MaxPermSize=128m -Xss1m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -Djava.security.egd=file:/dev/./urandom -cp /usr/share/bm-hps/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar org.eclipse.equinox.launcher.Main -application net.bluemind.proxy.http.launcher.hpslauncher
2.2 0.0 138156 1523968 /usr/lib/jvm/java-openjdk/bin/java -server -Xms128m -Xmx128m -XX:MaxPermSize=128m -Xss1m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -Djava.security.egd=file:/dev/./urandom -cp /usr/share/bm-locator/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar org.eclipse.equinox.launcher.Main -application net.bluemind.locator.app
2.1 0.0 129756 1657760 /usr/lib/jvm/java-openjdk/bin/java -server -Xms256m -Xmx256m -XX:MaxPermSize=128m -Xss1m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -Djava.security.egd=file:/dev/./urandom -cp /usr/share/bm-lmtpd/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar org.eclipse.equinox.launcher.Main -application net.bluemind.lmtp.id1
1.8 0.1 109152 1529312 /usr/lib/jvm/java-openjdk/bin/java -server -Xms128m -Xmx128m -XX:MaxPermSize=128m -Xss1m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -Djava.security.egd=file:/dev/./urandom -cp /usr/share/ysnp/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar org.eclipse.equinox.launcher.Main -application net.bluemind.ysnp.ysnp
1.6 0.1 98188 1523084 /usr/lib/jvm/java-openjdk/bin/java -Xrs -server -Xms128m -Xmx128m -XX:MaxPermSize=128m -Xss1m -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:CMSInitiatingOccupancyFraction=80 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -Djava.security.egd=file:/dev/./urandom -cp /usr/share/bm-node/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar org.eclipse.equinox.launcher.Main -application net.bluemind.node.server.nodelauncher
[/quote]
merci de ton retour jidea
ce serait donc un fonctionnement normal ? J’ai du mal à y croire… En tout cas ma supervision me montre que cela n’arrête pas de grimper…
total used free shared buffers cached
Mem: 8169960 7000432 1169528 0 105648 418320
-/+ buffers/cache: 6476464 1693496
Swap: 9578480 0 9578480
Sacha.
Hello,
pour diagnostiquer s’il y a vraiment un problème, il nous faudrait le résultat de la commande suivante :
bmctl memory
Les sorties doivent ressembler à ça :
bmctl memory
Memory used for 3852: 122756440
Memory used for 3971: 177570768
Memory used for 3403: 188135056
Memory used for 21312: 160397864
Memory used for 21154: 53178920
Memory used for 21619: 46166688
Memory used for 3429: 60866504
Memory used for 21662: 84872624
Memory used for 4890: 0
Memory used for 3442: 137099256
Total Blue Mind JVM memory: 1031044120 (983 MB)
(Exemple pris sur une prod avec une centaine d’utilisateurs actifs et 600 en base). Cette commande vous donne la consommation réelle totale de toutes les briques Java.
free
total used free shared buffers cached
Mem: 10242776 10078228 164548 0 334832 5637500
-/+ buffers/cache: 4105896 6136880
Swap: 4882428 107456 4774972
Comme chez vous, c’est principalement du cache disque qui est utilisé. La vrai mémoire “libre” c’est mauvais, et 6G dédiés au cache disque c’est parfait, ça veut dire que le système n’est pas sous pression.
Dans les paramètres que nous donnons à nos machines virtuelles Java, vous avez “-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp” qui va générer un fichier “hprof” dans /tmp quand l’une des JVM n’a plus de mémoire ce qui permettra d’identifier un leak mémoire éventuel ou le sous-dimensionnement d’un composant.
Les paramètres par défaut sont dimensionnés pour 4G, avec quelque chose comme 2G à l’ensemble des briques Java, 1G à postresql et 1G de “marge d’erreur” pour prendre en compte les composants pour lesquels le calcul est compliqué (cyrus qui va plutôt reposer sur le cache disque de l’OS plutôt qu’allouer ces propres buffer, etc).
Pour moi tout va bien sur vos installs.
tcataldo, merci pour ta réponse complète.
au passage j’ai découvert bmctl merci encore,
Donc tout va bien la situation est normale si je comprends bien ?
Je dois positionner mes indicateurs de supervision différemment sur la mémoire.
Sacha.
à quand un cli d’admin bm via cette commande ?
On y pense. La prochaine version devrait apporter 2 choses interessantes dans ce sens :
- un “proxy” SOAP pour les API Blue Mind pour permettre de faire de la programmation/scripting autour des APIs Blue Mind avec des langages que nous n’utilisons pas forcément au quotidien (j’ai ajouté un sample python tout à l’heure et nous avons fait des tests .net/c# dans l’aprem)
- pour le monitoring on commence à exporter pas mal de choses via JMX, principalement des variables liées aux temps de réponses. Les outils classiques savent généralement historiser des compteurs/jauges JMX.
centraliser les commandes via bmctl serait une bonne chose dans l’esprit des *ctl des *bsd !
je suis ça de près pour un module nrpe/nagios/shinken/…
On peux considérer ce thread comme résolu.
Merci tcataldo.
Petit ajout:
je continue à avoir ma mémoire occupée, plus précisément ce sont les caches mémoires qui ne sont pas libérés.
Ma solution à défaut de mieux et de libérer manuellement les caches avec une entrée crontab du genre:
sync; echo 3 > /proc/sys/vm/drop_caches
C’est une très mauvaise idée et le cache disque est très bénéfique. Cette commande est plutôt là pour exécuter des benchmarks de disque dur et s’assurer que les données ne viennent pas de la ram.
cache disque ? Dans le cas présent il s’agit uniquement de cache mémoire non ?
C’est un cache en mémoire qui copie le contenu le plus utilisé de votre disque. Le vider va obliger le kernel à le reconstruire et générer des I/Os inutiles.
Complètement d’accord tcataldo.
Dans le fond, ma démarche ici est de comprendre comment mesurer la mémoire libre car ma sonde NRPE se basant sur la commande free (et censée prendre en compte le cache) n’est pas pertinente.
j’ai observé de près /proc/meminfo
c’est VmallocUsed qui a grandit d’1Go cette nuit.
c’est plus qu’étonnant, vmalloc c’est interne au noyau en principe (et ce n’est donc pas à soustraire de memused)
Sacha.
En tout cas je ne pense pas que ce soit lié à Blue Mind. http://lwn.net/images/pdf/LDD3/ch08.pdf
Démarrer un server X sur la machine peut faire grossir cette valeur. Sur les installs que j’ai à dispo (virtu vmware), la valeur est légèrement supérieure à 256meg, ce qui correspond à la réservation par les pilotes video vmware, aux buffers des cartes e1000, etc.
/proc/vmallocinfo vous permettra de comprendre quel module fait des réservations dans cette zone.
Tu as raison tcataldo, cela vient d’une autre brique, ZFS on linux, qui abuse du vmalloc, le kernel voit cette mémoire allouée alors que c’est du cache pour pour ZFS dans ARC.
Merci tcataldo pour ton expertise.