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
 

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.

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

 
 
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.  

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

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

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

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

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
 

public class MemLoadTester {
        public static void main ( String[] args ) {
 
            long rand;
            char cr;
            char[] cra = new char[2048];
 
            for ( int i=0; i<2048; i++) {
                rand = 70 + Math.round( Math.random() * 50);
                cr = (char) rand;
                cra[i] = cr;
            }
 
            int entities = 800000;
            int blocksize = 10240;
 
            String[] zz = new String[ entities];
 
            // Java char type is 2bytes.
            System.out.println (" Each box indicates the creation of ~40Meg" );
 
            for ( int j=0; j<entities; j++ ) {
                zz[j] = new String( cra );
                if (j != 0 && j % blocksize == 0 ) {
                    System.out.print ( "#" );
                }
 
                if (j != 0 && j % (blocksize * 10) == 0 ) {
                    System.out.println ( "" );
 
                }
 
            }
 
            System.out.println( "\n" );
 
        }
    System.out.println ( " Success " );
}

 
et ensuite
 

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)

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

sockets ou web services c bien ce que je disais

A non il y a RMI que tu n'avais pas dit.
 
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?

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 )

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

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...