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 ....
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Lionel
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
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
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
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.
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.
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
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.
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.
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
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 ?
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 ?
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
On Thu, 26 Jan 2006 11:36:04 +0100, Pif wrote:
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.
On Thu, 26 Jan 2006 11:36:04 +0100, Pif <pif@nospam.fr> wrote:
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.
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
On Thu, 26 Jan 2006 11:36:04 +0100, Pif wrote:
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é...)
On Thu, 26 Jan 2006 11:36:04 +0100, Pif <pif@nospam.fr> wrote:
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é...)
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
"Pif" a écrit dans le message de news:drkvh8$qat$
On Thu, 26 Jan 2006 11:36:04 +0100, Pif wrote:
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
"Pif" <pif@nospam.fr> a écrit dans le message de
news:drkvh8$qat$1@eerie.ema.fr...
On Thu, 26 Jan 2006 11:36:04 +0100, Pif <pif@nospam.fr> wrote:
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
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
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.
On Mon, 30 Jan 2006 13:07:36 +0100, Pif <pif@nospam.fr> wrote:
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.
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
On Mon, 30 Jan 2006 13:07:36 +0100, Pif wrote:
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.
On Mon, 30 Jan 2006 13:07:36 +0100, Pif <pif@nospam.fr> wrote:
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?
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?
