Détecter que le serveur va saturer pour le considérer comme indisponible, avant qu'il ne sature vraiment.

Bonsoir à tous,

j'aimerais trouver un moyen pour que JBoss se rende compte qu'il va bientôt saturer (un "out of memory" ne va pas tarder !) et se coupe alors tout seul, ou prévienne le load balancer Apache explicitement qu'il faut le considérer comme non-disponible.

Le problème que j'ai aujourd'hui c'est que tant que la connexion entre le Apache et JBoss persiste, Apache ne considère pas le JBoss comme "indisponible" alors qu'il n'arrive plus à répondre aux requêtes des utilisateurs.
Ça se finit en "kill -9" avec pour conséquences des transactions Oracle mal terminées (2 PC) qui polluent ensuite, etc.

Avez-vous des pistes à me proposer pour que je fouille ?
J'imagine qu'il y a un mécanisme que je ne connais pas ou utilise mal.

Merci de votre aide :)

--
Mickaël

La méthode la plus efficace que je connaisse c'est d'analyser pourquoi le serveur sature afin d'effectuer les corrections nécessaires (consommation mémoire, réduction du nombre de thread de service, gestion correcte des transaction, ...)

Il n'y a pas de moyen miracle de détecter qu'on arrive en out of memory pour une bonne raison, ça peux survenir à partir de rien :p


Maintenant, tu peux avoir de l'aide, avec par exemple les MemoryMXBean qui peuvent t'envoyer des events quand certains niveaux sont dépassés. Mais ce n'est pas juste à partir de ça que tu arrivera à sauver la machine. Tu peux avoir de nombreux dépassements sans importances tout comme tu peux avoir un outofmemory au premier dépassement.

Tu parle de rajouter des machines au pool, mais démarrer un jboss avec les applications qui sont dedans, ça prend entre 2 et 10 minutes en général. C'est trop lent de toutes façons pour absorber un pic.

Le plus important selon moi, c'est d'analyser combien occupe de mémoire une requête en moyenne, calculer combien tu peux donc en traiter raisonnablement en paramètre, et ensuite configurer le jboss pour ne pas traiter plus de ce nombre de requete en parallèle.

Bonjour tchize_

et merci pour ta réponse, mais c'est en partie un peu à côté :)

Je ne cherche pas ici à trouver un moyen d'éviter les soucis, mais un moyen pour qu'une instance qui a des soucis puisse être considérée comme indisponible par le load balancer (Apache + mod_jk).
Aujourd'hui ce qui se passe c'est que petit à petit elle ne répond plus assez vite (puis plus du tout à cause des jeux de timeout) aux utilisateurs, alors que le load balancer continue de lui envoyer des requêtes ...

Comme je le disais, l'hébergeur n'arrive souvent même plus à l'éteindre proprement et fait du "kill -9", etc.


Par contre, évidemment ;) pendant ce temps l'équipe dont je fais parti a cherché (et trouvé \o/ ) pourquoi les instances se sont mises à tomber à cause de problèmes de OOM, etc.


Je vais regarder "MemoryMXBean", merci beaucoup.

Enfin, je n'ai pas compris pourquoi tu parles de "rajouter des machines au pool"... ce qui est exclu en l'occurrence.


Du côté de "configurer le jboss pour ne pas traiter plus de ce nombre de requete en parallèle", ce n'est pas ce que je cherche non plus... car c'est déjà fait et le hic c'est que les instances tombent alors qu'elles ne devraient pas ;)

Merci encore.

pour savoir si une instance marche toujours, le plus simple est de la monitorer en extérieur, en créant un requête sur cette instance spécifique (et non sur le load balancer) et en regardant le temps de réponse déterminer si oui ou non il faut redémarrer cette instance.

J'ai parlé de rajouter des machines au pool parce que je ne voyais pas trop quelle autre option tu envisageait une fois que tu avais déterminé qu'il y avait un problème.

Maintenant, tu dis que les machines ralentissent progressivement, n'est-ce pas (oui c'est moche) possible de redémarrer les instances tous les jours, chacune à une heure différente pour ne pas affecter la charge?

Mais tout ça n'est que de l'emplâtre en attendant que le problème de font (bugs dans la webapplication) soit corrigé par l'équipe de dev ;)