Plusieurs JVM pour étendre la mémoire disponible?

Plusieurs JVM pour étendre la mémoire disponible? - Java - Programmation

Marsh Posté le 03-09-2008 à 15:36:24    

Bonjour,
 
Voici le problème auquel je suis confronté:
J'ai un programma java qui tourne sur mac OS server, la mémoire de la jvm est étendue au maximum (environ 2Go), malgré cela , certains calculs sur des matrices spécifiques et qui font la valeur ajoutée de l'application, consomme souvent toute la mémoire et plante la jvm.
 
Je cherche donc une façon d'étendre la mémoire disponible pour mon programme java, le problème c'est que pour une jvm, quelque soit le matériel et l'OS on ne peut monter au delà de 2G...Je pense donc à répartir les calculs sur 2 ou plus JVM, le tout sur une (ou plusieurs) machine qui puisse encaisser ceci...En restant très ouvert concernant le matériel et l'OS qui conviendrait. Sachant que je préférerait rester avec une jvm en 32 bits...
 
Je trouve peu d'informations sur ce genre d'architecture, est ce que cela existe? Avez vous déjà pratiqué une façon ou une autre d'étendre la mémoire java? Si vous avez des information sur un moyen d'étendre la mémoire, je suis preneur...Merci beaucoup d'avance.
ah oui pour le moment j'utilise jdk et jre 1.5...
 
Jp
 

Reply

Marsh Posté le 03-09-2008 à 15:36:24   

Reply

Marsh Posté le 03-09-2008 à 16:49:52    

Il y a deux solutions a ton probleme :
 
1-Augmenter la mémoire disponible
2-Réduire la consommation mémoire (optimisation, chasse aux memory leaks etc...)
 
Je te laisse deviner quelle solution est la meilleure.


---------------
Hobby eien /人◕ ‿‿ ◕人\
Reply

Marsh Posté le 03-09-2008 à 16:58:12    

surtout que comme il a dit, la première est impossible ;)
 
ceci dit, jeanfilou, je ne connais pas spécialement java, mais ta limitation des 2 Go, ça ressemble plus à une limitation de l'environnement 32 bits qu'autrechose... pourquoi ne pas vouloir tenter avec une 64 bits ? (en supposant que la jvm peut dépasser 2 Go sur une plateforme 64 bits)
 
en effet, sous windows tout du moins, 2 Go est justement la limite adressable pour un programme 32 bits. c'est donc assez tentant de faire le rapprochement ;)


Message édité par MagicBuzz le 03-09-2008 à 16:58:32
Reply

Marsh Posté le 03-09-2008 à 17:06:48    

Tamahome a écrit :

Il y a deux solutions a ton probleme :
 
1-Augmenter la mémoire disponible
2-Réduire la consommation mémoire (optimisation, chasse aux memory leaks etc...)
 
Je te laisse deviner quelle solution est la meilleure.


 
 
Merci pour le conseil, le problème est attaqué sous les 2 angles mais on m'a confié justement de travailler sur les possibilités d'extension mémoire, et plus généralement sur les méthodes pour distribuer l'exécution d'un programme java sur plusieurs jvm, pour accroître la mémoire certainement, mais peut-être aussi pour gagner en souplesse de ressources cpu aussi, à l'avenir...selon le nombres de connections à notre logiciel...
 
Voilà donc je suis toujours preneur de méthodes pour faire tourner un programme java sur plusieurs jvm et avoir des idées sur comment ces jvms pourront communiquer entre elles...
 
Merci d'avance.  :)

Reply

Marsh Posté le 03-09-2008 à 17:08:24    

Tamahome a écrit :

Il y a deux solutions a ton probleme :
 
1-Augmenter la mémoire disponible
2-Réduire la consommation mémoire (optimisation, chasse aux memory leaks etc...)
 
Je te laisse deviner quelle solution est la meilleure.


3-dégager le truc qui prend de la mémoire pour que ça en prenne moins e.g. déplacer les traitements matriciels dans une extension C bindée via JNI


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 03-09-2008 à 17:08:37    

ben à part jouer avec des sockets et/ou web service, je vois pas trop de solution "simple".

Reply

Marsh Posté le 03-09-2008 à 17:11:58    

jeanfilou > J'ai l'impression que tu es entrein de nous demander comment mettre en place, en java, un système de calcul distribué.

Reply

Marsh Posté le 03-09-2008 à 17:13:57    

pourquoi, c'est pas ça sa question ? c'était pourtant explicite :??:


Message édité par MagicBuzz le 03-09-2008 à 17:14:12
Reply

Marsh Posté le 03-09-2008 à 17:26:47    

en tout cas, système distribué mis à part, la limitation des 2 Go provient bien de l'OS 32 bits.
avec une JVM 64 bits, plus de soucis
 
http://www.theserverside.com/discu [...] d_id=26347
 

Citation :


The really problem on Xmx limit is the JVM  
Posted by: Irakli Nadareishvili on septembre 25, 2004 in response to Message #135986  
I performed memory test on an Athlon AMD64 laptop with
Mandrake 10 AMD64 and Sun JDK 1.5RC for AMD64.
 
test program started with 3.2GB memory limit setting
and the test program was able to consume 2.6G memory.
 
The physical RAM on the laptop is about 900M so most
of the test was using SWAP space and it became too
slow after 2.6G.
 
I should be able to have access to an Opteron with large-enough RAM, soon, so I am going to repeat the same test and post the results, here.
 
In any case, the following is the simple test program I was using:
 

Code :
  1. public class MemLoadTester {
  2.        public static void main ( String[] args ) {
  3.  
  4.            long rand;
  5.            char cr;
  6.            char[] cra = new char[2048];
  7.  
  8.            for ( int i=0; i<2048; i++) {
  9.                rand = 70 + Math.round( Math.random() * 50);
  10.                cr = (char) rand;
  11.                cra[i] = cr;
  12.            }
  13.  
  14.            int entities = 800000;
  15.            int blocksize = 10240;
  16.  
  17.            String[] zz = new String[ entities];
  18.  
  19.            // Java char type is 2bytes.
  20.            System.out.println (" Each box indicates the creation of ~40Meg" );
  21.  
  22.            for ( int j=0; j<entities; j++ ) {
  23.                zz[j] = new String( cra );
  24.                if (j != 0 && j % blocksize == 0 ) {
  25.                    System.out.print ( "#" );
  26.                }
  27.  
  28.                if (j != 0 && j % (blocksize * 10) == 0 ) {
  29.                    System.out.println ( "" );
  30.  
  31.                }
  32.  
  33.            }
  34.  
  35.            System.out.println( "\n" );
  36.  
  37.        }
  38.    System.out.println ( " Success " );
  39. }




 
et ensuite
 

Citation :


But then - would not be it much harder than just getting 64-bit processor servers?
 
By the way, I did run the same test (mentioned in my last post, anove) on a 64-bit server (AMD64) with enough RAM and the results were beautiful - very fast, no limit.
 
Go for 64bit!  


Message édité par MagicBuzz le 03-09-2008 à 17:28:30
Reply

Marsh Posté le 03-09-2008 à 17:29:46    

MagicBuzz > Je pense que si, mais c'est parfois en mettant un nom sur une technique qu'on trouve les infos amenant à la solution.
En tout cas je ne vois pas comment donner une réponse précise à une question aussi vaste :
- il existe plusieurs moyens permettant de faire dialoguer des programmes écrit en java
- l'implémentation d'un tel système dépend en partie de l'architecture du programme  déjà existant bien que ça passe en général par une architecture interne de type "module" (j'ai pas le bon terme mais j'espère qu'on se comprend)


Message édité par omega2 le 03-09-2008 à 17:30:27
Reply

Marsh Posté le 03-09-2008 à 17:29:46   

Reply

Marsh Posté le 03-09-2008 à 17:44:48    

Ok

 

Merci pour ces infos,
 en effet MagicBuzz, se tourner vers du 64 bit aurait pu être intéressant mais en fait on vient de m'insister sur le fait que le programme va être amené à tourner sur d'autres machines, chez nos clients (probablement équipés en 32 bits), pour des raisons de maintenance/évolution on est finalement obligé de garder une seule solution en 32 bits.

 

Est ce que ce que je souhaite faire s'appelle vraiment du calcul distribué...peut être pas, en effet l'idée plutôt que de partager du temps processeur entre différentes machines sur une même tâche serait peut-être de confier l'éxécution de certaines tâches complètement à une jvm, par exemple. Je n'ai pas encore les idées claires sur les possibilités de répartition  de travail entre différentes jvm mais  je vais regarder de plus près ce sujet, notament autour des sockets, c'est bien ça?... si vous avez de bons liens pour commencer...
Merci ...

 

Tiens je viens de trouver cette bribe de conversation sur un forum, des pistes que j'explore de ce pas....

 

What is the best way of communicating between two different JVM's, running
on the same machine?

 

There are several possibilities using:
- sockets
- RMI or Remote Method Invocation (serialized objects over sockets)
- EJB (Application server) to clients
- Servlet/JSP (Application Server) to clients

 



Message édité par jeanfilou le 03-09-2008 à 17:48:05
Reply

Marsh Posté le 03-09-2008 à 17:51:04    

sockets ou web services c bien ce que je disais [:magicbuzz]

Reply

Marsh Posté le 03-09-2008 à 18:08:32    

A non il y a RMI que tu n'avais pas dit. :p
 
jeanfilou > J'ai peut être mal compris un truc : actuellement ton programme traite plusieurs matrices en parallèle ou une seule? D'ailleurs en passant, vous estimez que le programme consommerait combien de mémoire au maximum s'il n'avait qu'une seule matrice à traiter à la fois et aucune autre matrice de chargé en mémoire?

Reply

Marsh Posté le 03-09-2008 à 19:57:50    

Ouaho ... S'il doit commencer à sérialiser et envoyer par socket des objets de cette taille là, ça va pas entre le programme plus léger et rapide :/
 
omega2 : S'il traite plusieurs matrices en // le problème serait (selon moi) assez "vite" réglé en écrivant les matrices dans un fichier temp et en les traitant une par une..  
Ce qui n'empêcherait pas un calcul distribué rudimentaire.. Mais bon je me suis jamais trouvé dans ce cas de figure (merci le 64bit :D )


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 04-09-2008 à 01:58:56    

Comme dit avant, les réponses qu'on peut te donner dépendent fortement du type de calcul que tu dois faire :
 - n matrices à traiter en parallèle (pas dur si les calculs sur les différentes matrices sont indépendants)
 - traitement d'une matrice énorme à répartir sur plusieurs JVM/machines (j'ai l'impression que c'est ça ton problème)
     => voir si c'est possible de découper en unités de traitement indépendantes

 

quelques lectures trouvées sur le net :
http://www.google.fr/search?rlz=1C [...] +distribué
http://fr.wikipedia.org/wiki/Calcul_distribué
http://systeme.developpez.com/cours/#reparti


Message édité par Bidem le 04-09-2008 à 01:59:50
Reply

Marsh Posté le 04-09-2008 à 12:57:01    


Après quelques lectures...(Merci bidem pour les références)
 
Omega 2> Je les ait appelées ainsi mais ces matrices ne sont pas des matrices de chiffres 'mathématiques', il s'agit plutôt du résultat de recherche sur une bdd en rdf, et c'est l'ensemble des requêtes qui est gourmand en ram plutôt que des calculs matriciels, j'aurais du préciser plus tôt, dsl tout le monde pour la confusion. Le problème est plutôt je pense dans la charge ponctuelle de la memoire vive que dans la durée d'occupation cpu. Cela reste un besoin de répartition de toute façon...
En fait (/r eso_ch) la taille des objets à passer ne serait pas immense mais c'est intéressant d'entendre que l'envoi d'objets par socket peut être gourmand.
 
 
Apparemment Java RMI et Corba sont les deux technos qui reviennent le plus souvent pour de la programmation 'répartie' disons...orientée objet.
Avant que je puisse tester les bénéfices d'une éventuelle architecture distribuée, il va falloir incrémenter ma réflexion entre la modularisation possible de mon programme et les possibilités offertes par la techno de 'répartition' que je vais choisir, et puis les possibilités de gain de performance offert...
 ce n'est pas une mince affaire, mais je vais prendre le temps.  
De toute façon le programme est suffisamment ambitieux pour qu'un jour ou l'autre on ait besoin de répartir la charge sur plusieurs machines ( java et physiques!) et la programmation répartie c'est l'avenir...Allons y gaiement.
 
merci encore, hésitez pas à alimenter encore si vous avez un retour, une expérience, des tutoriaux sympas sur ces technos je suis preneur...

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed