limite mémoire machine virtuelle sous windows

Le
Pif
Bonjour, ma machine virtuelle avec les options -Xmx et -Xms n'accèpte
pas de dépasser les 1,2 à 1,5 Go de RAM alouée en général (suivant la
machine) et sous windows.

J'aimerais savoir s'il y a des astuces, possibilités pour utiliser une
RAM de 2 Go voir plus .

Merci !
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Lionel
Le #209281
Pif wrote:
Bonjour, ma machine virtuelle avec les options -Xmx et -Xms n'accèpte
pas de dépasser les 1,2 à 1,5 Go de RAM alouée en général (suivant la
machine) et sous windows.


Voir le thread sur gmane.comp.java.french.general qui concernait ce sujet:
http://permalink.gmane.org/gmane.comp.java.french.general/3487

Jean-Louis Liagre
Le #209280
Pif wrote:
Bonjour, ma machine virtuelle avec les options -Xmx et -Xms n'accèpte
pas de dépasser les 1,2 à 1,5 Go de RAM alouée en général (suivant la
machine) et sous windows.

J'aimerais savoir s'il y a des astuces, possibilités pour utiliser une
RAM de 2 Go voir plus ....

Merci !


Java ne s'alloue pas de la RAM, mais de la mémoire virtuelle.

Sous un O/S 32 bits, la mémoire virtuelle adressable est de 4 giga-octets.
Windows partage en deux cet espace, 2 Go pour le système et
2 Go pour l'application (ici la JVM).

La JVM a besoin de mémoire pour ses besoins propres (code, pile, etc), ce
qui diminue la taille disponible, la mémoire retournée doit aussi etre
fournie en un seul bloc contigu, ces deux point doivent expliquer la
limite observée.

Il semble qu'il soit possible de paramétrer Windows et Linux pour
changer le partitionnement de la mémoire virtuelle (3 Go / 1 Go).
HIGHMEM avec linux, /3GB avec windows:
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

Unix (Solaris) n'a pas cette limite, et permet de se
rapprocher des 4 gigas en 32 bits (3.5 Go par exemple).

Avec Solaris en 64 bits, ces limites disparaissent.

Syrion
Le #209226
Et sous Windows x64, c'est pareil donc ?
Cela explique donc pourquoi AIX qui est un unix 64bit n' a pas de
problème sur des serveurs que je connais à allouer 512Mo chacune des
12 JVM (12JVM par machine physique, soit 6Go pour les serveurs
d'applications et 2Go pour le reste)?

Au passage, pour des raison de garbage collecting, n'est-il pas plus
intéressant d'avoir plusieurs JVM se partageant la mémoire que 1 seule
énorme ?

Pif wrote:


Java ne s'alloue pas de la RAM, mais de la mémoire virtuelle.

Sous un O/S 32 bits, la mémoire virtuelle adressable est de 4 giga-octets.
Windows partage en deux cet espace, 2 Go pour le système et
2 Go pour l'application (ici la JVM).

La JVM a besoin de mémoire pour ses besoins propres (code, pile, etc), ce
qui diminue la taille disponible, la mémoire retournée doit aussi etre
fournie en un seul bloc contigu, ces deux point doivent expliquer la
limite observée.

Il semble qu'il soit possible de paramétrer Windows et Linux pour
changer le partitionnement de la mémoire virtuelle (3 Go / 1 Go).
HIGHMEM avec linux, /3GB avec windows:
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

Unix (Solaris) n'a pas cette limite, et permet de se
rapprocher des 4 gigas en 32 bits (3.5 Go par exemple).

Avec Solaris en 64 bits, ces limites disparaissent.


Pif
Le #209224
ben disons que quand t'as plueieurs JVM, t'as des variables statiques
différentes, un comportement général différent (garbage collecting,
gestion de cache dans certains systèmes de persistence ou connexion
JDBC, gestion des exception et E/S, etc.) qui peut donner plus de
robustesse ou plus d'efficacité suivant les besoins.

En général, les machines multiproc ne partagent pas forcément la ram
mais chaque proc a sa propre mémoire centrale. Je crois que c'est comme
ca sur les sun dans les souvenir... ca permet de paralleliser les
différents bus notamment, donc l'optimisation dans le cas de gros
systèmes multiproc est en général plus performante car s'il s'agit à vue
de nez d'un système multitache habituelle, l'architecture reste
parallélisée...

Je crois que la JVM dans ces cas la ne se parallélise pas, meme si on
fait du multithread, et ca c'est bien dommage...


Au passage, pour des raison de garbage collecting, n'est-il pas plus
intéressant d'avoir plusieurs JVM se partageant la mémoire que 1 seule
énorme ?



fabrice-pas-despame.bacchella
Le #210090
On Thu, 26 Jan 2006 11:36:04 +0100, Pif
En général, les machines multiproc ne partagent pas forcément la ram
mais chaque proc a sa propre mémoire centrale. Je crois que c'est comme
ca sur les sun dans les souvenir... ca permet de paralleliser les


Absolument pas. La mémoire est toujours logiquement partagé. Après en
fonction des archi, on peut rentrer dans des choses assez subtil, ou
il faut effectivement passer par un processeur pour atteindre la
mémoire qui est derrière.

Je crois que la JVM dans ces cas la ne se parallélise pas, meme si on
fait du multithread, et ca c'est bien dommage...
??

Dans quel cas ? Bien sur qu'une JVM ça se parallélise, sauf le GC, &
encore, ça existe des Glaneur de Cellules parallélisés.

Et sous Windows x64, c'est pareil donc ?
Cela explique donc pourquoi AIX qui est un unix 64bit n' a pas de
problème sur des serveurs que je connais à allouer 512Mo chacune des
12 JVM (12JVM par machine physique, soit 6Go pour les serveurs
d'applications et 2Go pour le reste)?
Rien à voir. Le 64 bits permet d'avoir plus de 4 Go par application.

La mémoire physique totale que gère l'OS & le processeur, c'est un
autre combat, plus dépendant du hardware & de la MMU.

Pif
Le #210014
On Thu, 26 Jan 2006 11:36:04 +0100, Pif
Je crois que la JVM dans ces cas la ne se parallélise pas, meme si on
fait du multithread, et ca c'est bien dommage...


??
Dans quel cas ? Bien sur qu'une JVM ça se parallélise, sauf le GC, &
encore, ça existe des Glaneur de Cellules parallélisés.


j'ai pris un serveur sun 8 proc, j'ai lancé une JVM avec multithread
(1.4.2), et au résultat, mon programme plafonne à 12% de la CPU totale
du système... alors si t'as une explication autre que je fait que pour
paralléliser une JVM, il faut en lancer plueieurs je veux bien...

en plus, tous les test sur les PC dual core montre qu'il n'y a d'intérêt
que si on utiliser plusieurs prog à la fois, et que les logiciels
traditionnels (les jeux non paralléliser) n'ont aucun bénéfice.

dans la meme expérience, dans mes souvenir, (mais la je suis moins
formel), je n'ai jamais pu exploiter les 32 Go de RAM et uniquement 4 Go
pour mon proc (enfin un peu moins dans la réalité...)


jlp
Le #210013
"Pif" news:drkvh8$qat$
On Thu, 26 Jan 2006 11:36:04 +0100, Pif
Je crois que la JVM dans ces cas la ne se parallélise pas, meme si on
fait du multithread, et ca c'est bien dommage...


??
Dans quel cas ? Bien sur qu'une JVM ça se parallélise, sauf le GC, &
encore, ça existe des Glaneur de Cellules parallélisés.


j'ai pris un serveur sun 8 proc, j'ai lancé une JVM avec multithread
(1.4.2), et au résultat, mon programme plafonne à 12% de la CPU totale
du système... alors si t'as une explication autre que je fait que pour
paralléliser une JVM, il faut en lancer plueieurs je veux bien...

en plus, tous les test sur les PC dual core montre qu'il n'y a d'intérêt
que si on utiliser plusieurs prog à la fois, et que les logiciels
traditionnels (les jeux non paralléliser) n'ont aucun bénéfice.

dans la meme expérience, dans mes souvenir, (mais la je suis moins
formel), je n'ai jamais pu exploiter les 32 Go de RAM et uniquement 4 Go
pour mon proc (enfin un peu moins dans la réalité...)
Voir le doc de l'expert de la parallélisation en Java Doug Lea

kttp://www.jaoo.org/jaoo1999/schedule/DougLeaExploiting.pdf



fabrice-pas-despame.bacchella
Le #210646
On Mon, 30 Jan 2006 13:07:36 +0100, Pif
j'ai pris un serveur sun 8 proc, j'ai lancé une JVM avec multithread
(1.4.2), et au résultat, mon programme plafonne à 12% de la CPU totale
du système... alors si t'as une explication autre que je fait que pour
paralléliser une JVM, il faut en lancer plueieurs je veux bien...


Et bien sur, c'est la JVM qui en est la cause mais pas ton programme
? Je me souviens d'une nuit blanche passé à résoudre un gros problème
de perf, avec une machine sous-utilisée. En, fait, le développeur
avait abusé des synchronize, qu'il avait en fait placé "au cas où".
Moralité, un seul processeur était utilisé à la fois.


en plus, tous les test sur les PC dual core montre qu'il n'y a d'intérêt
que si on utiliser plusieurs prog à la fois, et que les logiciels
traditionnels (les jeux non paralléliser) n'ont aucun bénéfice.


Quels test ? Surement pas tous. L'utilisation de plusieurs processeur
ne s'obtient pas pas opération du saint esprit ? Sur du code (C) ecrit
par des bons développeurs, je suis arrivé à 100% de CPU sur une
machine octo-processeur durant un bench. Et si tout les processeurs
des consoles de jeux dernières générations sont multi-coeur, ce n'est
surement pas par hasard.


dans la meme expérience, dans mes souvenir, (mais la je suis moins
formel), je n'ai jamais pu exploiter les 32 Go de RAM et uniquement 4 Go
pour mon proc (enfin un peu moins dans la réalité...)


Faut utiliser un OS & une JVM 64 bits pour pouvoir utiliser plus de
4Go.

Alain
Le #210642
On Mon, 30 Jan 2006 13:07:36 +0100, Pif
j'ai pris un serveur sun 8 proc, j'ai lancé une JVM avec multithread
(1.4.2), et au résultat, mon programme plafonne à 12% de la CPU totale
du système... alors si t'as une explication autre que je fait que pour
paralléliser une JVM, il faut en lancer plueieurs je veux bien...
Et bien sur, c'est la JVM qui en est la cause mais pas ton programme

?


tout à fait...
quelle technique de parallélisation as tu utilisé ?
c'est un serveur avec plein de requête parallèles.
tu a créé plein de thread et pas trop de synchro inutiles pour que ça
tourne en parallèle au moins 8 fois?

décrit ton algorythme, au moins sa structure.


Publicité
Poster une réponse
Anonyme