Mémoire et serveurs

Version imprimable

02/08/2011, 11h02
Youpetitou

Mémoire et serveurs

Bonjour,

Je suis nouveau dans la communauté et j'espère avoir posté au bon endroit.
Le titre n'est pas très clair et je vais tenter de m'expliquer.

Je suis en train de développer un petit jeux de gestion multi-joueur entièrement en java et en ligne. Pour de nombreuses raisons, j'ai choisi de faire fonctionner le client avec 4 serveurs différents: "login", "register", "update", "maingame".

Pour le moment, "login","register" et "update" sont fonctionnels et stables.:ccool:
Mais je trouve qu'ils consomment beaucoup trop de RAM pour le peux de taches qu'ils ont à effectuer.
Je les lance un par un sur le serveur en utilisant les options -Xms et -Xmx pour limiter leur consommation mais malgré ces intentions, cela reste énorme (env 1,2G pour peu de sollicitation :aie:).

Avez vous des idées, des pistes ou des conseils à me donner pour améliorer quelques peu la gestion de la mémoire de ces appli ?

(je ne suis pas trop entré dans les détails pour éviter que sujet soit illisible... n'hésitez pas à me demander de préciser certains points !)

Merci !
02/08/2011, 11h05
kolodz

Pourquoi avoir 4 serveurs pour 4 fonctions ?

Cordialement,
Patrick Kolodziejczyk.
02/08/2011, 11h07
dinobogan

Une optimisation de mémoire se fait par une analyse fine de l'architecture et de l'implémentation. Mais tu ne donnes aucun détail :roll:
Sinon, je suis curieux de connaître quelques raisons qui t'ont poussées à faire 4 serveurs différents au lieu d'un seul.
02/08/2011, 11h11
Youpetitou

Pour pouvoir déployer, tester, redémarrer, mettre à jour facilement.
Je suis encore novice en java et je me fais un peut la main sur ce petit projet. C'est peut être un choix idiot de ma part. Au point ou j'en suis je peux tout à fait faire machine arrière donc n'hésitez critiquer ce choix.

EDIT: Je souhaite avoir au moins deux servuers en fait ... Car l'objectif est que les joueurs puissent lancer leur propre servuer de jeu mais je souhaite tout de même garder la gestion des comptes.

Pour ce qui concerne l'architecture (j'espère que je ne vais pas répondre à côté) c'est plutôt basique. chaque server a son thread qui accepte les connexions des joueurs. A chaque connexion, un thread est lancé pour effectuer quelques tâches avec le client et se fermer après le travail accompli.
02/08/2011, 13h01
Logan Mauzaize

Citation:

Envoyé par dinobogan

Sinon, je suis curieux de connaître quelques raisons qui t'ont poussées à faire 4 serveurs différents au lieu d'un seul.

La plupart des MMO (tous ?) disposent d'un ou plusieurs serveurs "credentials" (google fait de même) et de plusieurs serveurs de jeux.
Les MMO sérieux ont même plusieurs clusters de serveurs de jeux.
Chaque grappe représente un serveur sur lequel tu crées un personnage et chaque cluster gère une zone géographique.
Dans certains jeux une même zone peut-être gérée par plusieurs clusters (ex: Guild Wars).

Citation:

Envoyé par Youpetitou

Pour ce qui concerne l'architecture (j'espère que je ne vais pas répondre à côté) c'est plutôt basique. chaque server a son thread qui accepte les connexions des joueurs. A chaque connexion, un thread est lancé pour effectuer quelques tâches avec le client et se fermer après le travail accompli.

Pense à utiliser un pool de thread.

Concernant la mémoire, il convient d'utiliser des profiler et des outils d'analysze.
Si ton projet est open-source, tu peux demander une licence spéciale pour YourKit.
Sinon tu as MemoryAnalyzer (plugin Eclipse, dispo en RCP) qui est déjà pas mal.
02/08/2011, 13h36
Youpetitou

Merci pour vos réponses.

Je vais essayer de me documenter un peut sur toutes tes propositions Nemek. (ca ne m'évoque pas grand chose à première vue :oops:)

Sinon j'ai quelques questions concernant la JVM. (encore une fois je n'y connais rien, d'habitude je me contente de faire des petites appli de rien du tout.)

Comment peut-on connaitre la mémoire nécessaire au bon fonctionnement d'un programme java ?

Je m'explique avec ce que j'ai pu constater: Quand je lance mon .jar sans les options -Xmx -Xms, une certaine quantité de mémoire est allouée au programme. Ensuite, lorsque j'ajoute ces options de façon à réduire la quantité de RAM utilisée, je remarque effectivement une diminution mais cela n'empêche pas pour autant le programme de tourner.

Est-il possible de déterminer la quantité minimale de RAM nécessaire au bon fonctionnement d'un programme ? avec un profiler ou tout autre outil d'analyse ?

Est-ce que l'option de lancement de la JVM "-server" permet d'optimiser l'utilisation de la mémoire ?

Est-ce que le fait de lancer 3 .jar différent lance 3 JVM différentes ? (ce qui j'imagine expliquerai une partie du problème :aie:)

Merci pour vos réponses :D
02/08/2011, 14h15
Logan Mauzaize

Ca fait beaucoup de questions un peu pointu :) Je vais essayer d'y répondre avec mes souvenirs (j'invite grandement les spécialistes à corriger/compléter)

Java sépare sa mémoire en 3 zones en gros : la mémoire de travail (ce que la JVM est en train de manipuler), la mémoire à court terme (les objets que tu as alloués et que tu ne réutiliseras pas), la mémoire à long terme (les autres objets, il me semble que cette "zone" est également découpée en deux).

Pour gagner du temps, la JVM se réserve (alloue) une certaine quantité de mémoire pour chaque zone même si elle ne l'utilise pas et augment "la mémoire allouée" par palier/ratio. La "mémoire utilisée" n'est donc pas toujours si conséquente par rapport à la mémoire allouée.
La mémoire utilisée fluctue en fonction des allocations mais également en fonction des passages du GC. Avant d'allouée à nouveau de la mémoire, la JVM va "potentiellement" chercher à en libérer dans ce qu'elle utilise.

Pour connaître la mémoire effectivement utilisée, tu peux utiliser des outils comme VisualVM qui est fourni avec le JDK.

Les paramètres "-Xmx -Xms" permettent de régler la taille (d'une des zones ou la somme des zones) mémoire. La JVM applique un ratio (modifiable) pour déterminer la taille de chaque zone mémoire en fonction de ces paramètres.

Le paramètre "-server" modifie le réglage de la taille des zones mémoires et également l'algorithme du GC. Cela a également d'autres effets (sur le JIT par exemple) mais globalement tu pourrais avoir le même fonctionnement en utilisant des paramètres de réglage.

Chaque fois que tu lances la commande "java" cela crée une nouvelle JVM (un processus). Cependant la JVM (la technologie) a des mécanismes de partage de ressources entre plusieurs processus.

Pour optimiser les paramètres mémoire, il faut bien connaître son programme et les mécanismes de Java afin de "tailler" chaque zone en fonction de l'usage qu'en fait le programme.
Il me semble qu'il y a un article sur le site à ce sujet

EDIT: Voici quelques liens
http://jmdoudoux.developpez.com/cour...on_memoire.php
http://gfx.developpez.com/tutoriel/java/gc/
http://blog.developpez.com/adiguba/p...es-de-memoire/
http://schmitt.developpez.com/tutoriel/java/memoire/
02/08/2011, 15h17
Youpetitou

Merci beaucoup pour tes réponses :D!

(Je n'imaginait pas que mes questionnements pouvaient toucher des problématiques si pointues 8O)

J'avais fait l'amalgame de "mémoire allouée" et "mémoire utilisée" :oops:.

Avant de passer des heures dans la documentation :aie: je vais quand même tester l'efficacité de mes serveurs à grande échelle (simulation d'un fort flux de connexions) et voir jusqu'où je peux réduire la quantité de mémoire allouée.

Je pense également m'intéresser de plus prêt aux pool de thread :)

Je vous tiens au courant si je trouve des choses intéressantes sur le sujet.

Encore merci ! :ccool:
02/08/2011, 16h30
dinobogan

Citation:

Envoyé par Nemek

La plupart des MMO (tous ?) disposent d'un ou plusieurs serveurs "credentials" (google fait de même) et de plusieurs serveurs de jeux.
Les MMO sérieux ont même plusieurs clusters de serveurs de jeux.
Chaque grappe représente un serveur sur lequel tu crées un personnage et chaque cluster gère une zone géographique.
Dans certains jeux une même zone peut-être gérée par plusieurs clusters (ex: Guild Wars).

Je suis d'accord, mais dans notre cas, le découpage en plusieurs serveurs concerne des fonctionnalités bien distinctes : login, création de compte, mise à jour et le serveur de jeu.

Youpetitou, d'un point de vue extérieur à la JVM, la mémoire allouée non utilisée reste inutilisable pour d'autres processus. Reste à savoir si la machine hôte a autre chose gourmand en ressources à effectuer.
Juste une suggestion : puisque tes 3 serveurs (login, register, update) fonctionne correctement, je t'encourage à passer au problème suivant. Il sera toujours temps, plus tard, de regrouper ces 3 serveurs en un seul si tu le souhaites. Mais c'est juste une suggestion : je ne connais pas tes objectifs sur ce projet, ni le temps que tu souhaites y consacrer, ni les ressources disponibles de la machine hôte... ;)
02/08/2011, 21h49
Youpetitou

Merci pour ta réponse dinobogan.
Je vais préciser un peut:

-Objectif: Créer un jeu multijoueur jouable et obtenir une centaine de joueurs actifs (c'est pas gagné ...)

-Le temps que je souhaite y consacrer n'est pas énorme, je ne travaille pas à temps plein dessus mais je me bloque minimum 1h/jour (ca peut aller jusqu'à 6 ou 7 heures !)

-La machine hôte actuelle: 2Go de RAM et core 2 duo (aucune idée de la ref mais les processus ne posent pas de problème) sous Débian lenny.

J'aurai aimé n'utiliser que 1Go de mémoire pour pouvoir faire tourner d'autres choses dessus mais pour le moment rien d'impératif.

J'ai fait quelques tests en générant un flux de 6000 upgrades/register/login en 10 min et ça passe tranquillement.
Pour le moment je vais me concentrer sur le serveur de jeu et je verrai par la suite pour la fusion des serveurs / problème de mémoire.

Encore merci !
03/08/2011, 00h41
tchize_

Citation:

Envoyé par Youpetitou

Mais je trouve qu'ils consomment beaucoup trop de RAM pour le peux de taches qu'ils ont à effectuer.
Je les lance un par un sur le serveur en utilisant les options -Xms et -Xmx pour limiter leur consommation mais malgré ces intentions, cela reste énorme (env 1,2G pour peu de sollicitation :aie:).

Ben tu leur met à tous un -Xmx de 64m et hop, ils sont coincé. Le garbage collector de java a la particularité d'être fainéant. Si il peux éviter un calcul compliqué en allouant plus de mémoire, il le fait :roll: Si tu limite pas la mémoire utilisée, la jvm va faire une boulimie mémoire
03/08/2011, 10h17
adiGuba

Citation:

Envoyé par tchize_

Ben tu leur met à tous un -Xmx de 64m et hop, ils sont coincé. Le garbage collector de java a la particularité d'être fainéant. Si il peux éviter un calcul compliqué en allouant plus de mémoire, il le fait :roll: Si tu limite pas la mémoire utilisée, la jvm va faire une boulimie mémoire

+1 Surtout en -server où la JVM va privilégier les performances brutes à l'occupation mémoire.

De même, faire bien attention à limiter au maximum la porté des variables, sinon le GC pourrait tarder à les libérer...

a++
03/08/2011, 10h23
Youpetitou

Merci pour ces propositions !
Je vais essayer ça dès ce soir :P

Citation:

Envoyé par adiGuba

De même, faire bien attention à limiter au maximum la porté des variables, sinon le GC pourrait tarder à les libérer...

Euh ... peux tu préciser un petit peu ? peut être avec un exemple ?
Je ne comprend pas vraiment de quoi tu parle en disant "limiter la porté des variables" :oops:
03/08/2011, 10h46
adiGuba

Citation:

Envoyé par Youpetitou

Euh ... peux tu préciser un petit peu ? peut être avec un exemple ?
Je ne comprend pas vraiment de quoi tu parle en disant "limiter la porté des variables" :oops:

C'est à dire qu'il faut les déclarer là où tu en a besoin.

Par exemple une variable locale d'une méthode doit être déclarée dans la dite-méthode. Il ne faut pas utiliser un attribut d'instance ou pire un attribut static.

Sinon tu risques de conserver inutilement des références, et donc de compliquer le travail du GC...

a++
03/08/2011, 13h05
tchize_

D'autant qu'avec les dernière jvm (java 7) les variable locale à la méthode qui n'en sortent pas ne passent même plus par le GC :)
03/08/2011, 13h16
Youpetitou

Miam bonne nouvelle ..; il va falloir que je mette tout ça à jour !
03/08/2011, 13h44
adiGuba

Plus globalement cela facilite le travail du GC, car on évites ainsi de conserver des références sur des objets inutiles...

a++