[Info-Versio][Résolu] Surcharge IO - le service BM-Mq est tombé

Bonsoir à tous

Mon serveur de messagerie est virtualisé sur une VM KVM d’un Host Proxmox.
Lors de l’installation d’autres serveurs virtuels, le Host est monté en surcharge IO (Load > 15)

J’ai vu une paralysie de mon serveur de mail.
Le redémarrage des services a tout réglé : le service Bm-Mq était tombé

Je regarderai donc les log demain soir pour plus d’info

Bonne soirée

Crdt
Poustiquet
Dernière version stable de BM

root@securemail:~# /etc/init.d/restart_bm_all.ksk
Stopping nginx: nginx.
Stopping Postfix Mail Transport Agent: postfix.
Waiting for BM Tomcat shutdown…
Waiting for Bmnode Server shutdown.
Waiting for Blue Mind lmtpd server shutdown…
Waiting for Bm-Hps Server shutdown…
Waiting for Blue Mind EAS Server shutdown…
Waiting for Blue Mind core Server shutdown…
Waiting for Blue Mind locator Server shutdown…
Bm-Mq Server not running.
Stopping PostgreSQL 8.4 database server: main.
sleep 10
Starting PostgreSQL 8.4 database server: main.
Bm-Mq Server started: 3531
BM Locator Server started: 3538
Blue Mind core Server started: 3544
Blue Mind EAS Server started: 3575
Bm-Hps Server started: 3585
Blue Mind lmtpd server started: 3600
Bmnode Server started: 3608
Using CATALINA_BASE: /usr/share/tomcat
Using CATALINA_HOME: /usr/share/tomcat
Using CATALINA_TMPDIR: /tmp
Using JRE_HOME: /usr/lib/jvm/java-1.6.0-openjdk
Starting Postfix Mail Transport Agent: postfix.
Starting nginx: nginx.

Si vous êtes sur debian alors ce problème est connu. La 1.0.9 le contourne.

Merci tcataldo pour ta réponse.

Effectivement je suis sous Debian, et le pire c’est que Pierre m’en avait déjà informé.
Mais je n’avais pas fait réellement le lien.

Mais ce n’est vraiment très problématique, cela n’arrive que lorsque le serveur est extrêmement sollicité sur une longue période.

D’ailleurs, j’ai lancé des tests de charges sur la machine physique. Et cela n’arrive pas forcement et pourtant j’ai 2 serveurs de productions virtualisés sur le même Host

Crdt
Poustiquet

Passage en [résolu]

En effet nous avons découvert le problème lors de taches intensives de provisionning d’event. Sur ubuntu “chez moi ça marche” et sur debian mon collègue avait un crash aléatoire de son mq au bout d’une 20aine de minutes.

Une segfault de jvm étant souvent liée à une librairie native, nous avons testé hornetq avec aio désactivé sur debian ce qui corrigeait le problème.

Au final nous l’avons désactivé pour toutes les distribs pour ne pas avoir ubuntu et redhat en aio et debian en nio. Le changement est anodin niveau perf, toutes les files hornetq de Blue Mind étant non persistantes et utilisées uniquement pour de la notification inter-process.

Il y aussi ça qui a motivé la modif https://access.redhat.com/knowledge/solutions/62016. Quand une brique censée améliorer les perfs déclenche ce genre de warnings sur toutes nos distribs (warning visible sur pas mal d’installs) autant l’éviter, au moins pour l’instant.

Voilà pour les détails sordides derrière ce problème et le correctif basique qui a été de virer libHornetQ64.so des packages.

Ok je vois .

Merci pour cette information

Je vais migrer mes 2 serveurs en 1.0.9 ce week end

Crdt
Poustiquet