Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Résolu] Augmenter la mémoire pour JOSM ?

Kypso

Bonjour à tous.

Je suis un nouvel utilisateur de linux (j'ai donc choisi fedora 16 pour me lancer) et je rencontre quelques souci de plantage avec le logiciel JOSM (pour editer openstreetmap).
Sous windows, il y a une manip qui consiste à augmenter la taille de la mémoire utilisable pour une application java: (C:\WINDOWS\system32\java.exe -jar -Xmx2048M "C:\path\josm-tested.jar")

Malheureusement, je suis incapable de trouver comment faire sous fedora pour pouvoir avoir la même chose, car lors d'une etape de verification de données nombreuses, la machine plante à tous les coups "freeze" ou "reboot". Je suis obligé de repasser sous windows pour faire la manip :\ .
Si quelqu'un pouvait m'aiguiller ce serait sympa 🙂

La seule commande trouvée sur le net que semble comprendre ma machine est celle ci:

$ java -jar -Xmx2048M /usr/share/java/josm.jar

mais qui me renvoie cette erreur:

Build-Date: 2012-04-16 13:53:54
Revision: 5181
Is-Local-Build: true

java.lang.NoClassDefFoundError: com/kitfox/svg/SVGException
        at org.openstreetmap.josm.gui.SplashScreen.<init>(SplashScreen.java:58)
        at org.openstreetmap.josm.gui.MainApplication.main(MainApplication.java:222)
Caused by: java.lang.ClassNotFoundException: com.kitfox.svg.SVGException
        at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
        ... 2 more

theboogymaster

Tu exécute la commande en root ?

WilQu

Bonjour,

Tu dois spécifier le classpath pour que java sache où trouver tous les jar nécessaires, soit en définissant la variable CLASSPATH, soit en précisant les jars via l’option -cp.

Cependant, je ne suis pas sûr que modifier la taille mémoire utilisée puisse résoudre ton problème. Si c’était un problème de mémoire, seule l’application planterait.

Kypso

Merci de vous pencher sur mon problème.

theboogymaster wrote:Tu exécute la commande en root ?

J'ai essayé en root mais ca donne la même chose

WilQu wrote:Tu dois spécifier le classpath pour que java sache où trouver tous les jar nécessaires, soit en définissant la variable CLASSPATH, soit en précisant les jars via l’option -cp.

Je ne sais pas quoi spécifier comme classpath :-?, ceci dit, le fichier josm.jar contien un JOSM.class. Est-ce qu'il ne devrait pas se debrouiller avec ca ?

Sinon, je peux peut être ajouter l'option -Xmx2048M directement dans le shell de lancement, mais je ne sais pas ou le mettre non plus.
Voici le josm.sh

#!/bin/sh 
# Simple wrapper script used to start JOSM

# to prefer jre version and not java-devel version
_prefer_jre=1

# Source functions library
if [ -f /usr/share/java-utils/java-functions ] ; then
  . /usr/share/java-utils/java-functions
else
  echo "Can't find functions library, aborting"
  exit 1
fi

# Configuration
MAIN_CLASS="JOSM"
BASE_JARS="josm metadata-extractor ant signpost-core commons-codec svgsalamander"

# Set parameters
set_classpath $BASE_JARS

# Let's start
run "$@"

WilQu wrote:Cependant, je ne suis pas sûr que modifier la taille mémoire utilisée puisse résoudre ton problème. Si c’était un problème de mémoire, seule l’application planterait.

Je ne sais pas vraiment ou chercher en dehors de ce problème de mémoire 🙁
C'est vrai que JOSM plante complètement ma machine, plus aucune commande ne répond, parfois le pc reboot tout seul, parfois non ...
Mon ecran reste bloqué comme ca
crashjosm

Un peu d'infos sur ma machine:
Core I7 920
3x2Go DDR3
Radeon HD 4870

Edit: J'ai désactivé l'Hyperthreding dans le bios et le problème semble avoir disparu
Petite question: Sur ma photo, la colonne mémoire correspond bien a ce qu'utilise josm en terme de ram ? (et non ram + swap) Car on entend partout qu'il faut mettre une option pour passer au dela des 256Mo. Est-ce toujours vrai ? 😐

WilQu

Kypso wrote:
WilQu wrote:Tu dois spécifier le classpath pour que java sache où trouver tous les jar nécessaires, soit en définissant la variable CLASSPATH, soit en précisant les jars via l’option -cp.
Je ne sais pas quoi spécifier comme classpath :-?, ceci dit, le fichier josm.jar contien un JOSM.class. Est-ce qu'il ne devrait pas se debrouiller avec ca ?

Non, car il dépend d’autres librairies. Ces librairies sont listées sous la variable BASE_JAR du script que tu as montré.

Kypso wrote: Petite question: Sur ma photo, la colonne mémoire correspond bien a ce qu'utilise josm en terme de ram ? (et non ram + swap) Car on entend partout qu'il faut mettre une option pour passer au dela des 256Mo. Est-ce toujours vrai ? neutral

Je n’ai jamais entendu dire qu’il y avait une limite de mémoire, et s’il y en avait une elle empêcherait aussi de swapper à mon avis. Pour ma part je te confirme avoir déjà dépassé allègrement les 256Mo sans préciser d’option.

Kypso wrote: Sinon, je peux peut être ajouter l'option -Xmx2048M directement dans le shell de lancement, mais je ne sais pas ou le mettre non plus.

Mieux vaut ne pas y toucher, car il sera écrasé à la prochaine mise à jour. Si tu as besoin de faire un script de lancement, écris-en un séparé plutôt.

Ton problème a l’air d’être un bug, mais je ne sais pas si c’est un bug du JOSM, du noyau, de la JVM ou d’autre chose… As-tu jeté un œil sur Bugzilla ?

Kypso

WilQu wrote:Je n’ai jamais entendu dire qu’il y avait une limite de mémoire, et s’il y en avait une elle empêcherait aussi de swapper à mon avis. Pour ma part je te confirme avoir déjà dépassé allègrement les 256Mo sans préciser d’option.

J'ai lu ça dans différentes pages du wiki d'openstreetmap. Par exemple ici et là, mais je n'ai jamais cherché plus loins l'étendue de cette option.

Kypso wrote: Ton problème a l’air d’être un bug, mais je ne sais pas si c’est un bug du JOSM, du noyau, de la JVM ou d’autre chose… As-tu jeté un œil sur Bugzilla ?

Mon edit un peu plus haut est peu être passé inaperçu. J'ai désacivé l'hyper threading dans le Bios (processeur Core i7) et tout est rentré dans l'ordre.
C'est le fait que le pc plante toujours entre 12 et 13% qui m'a donné l'idée. 12,5% etant la charge max admissible sur un coeur logique (100/8 le compte est bon ). Maintenant la charge processeur monte jusqu'a 50% , donc je pense qu'il y a un problème entre l'appli ou JVM et l'hyper threading.

Voila, je vais pouvoir continuer a travailler tranquilement sous fedora. 🙂
Merci.

WilQu

Kypso wrote:
WilQu wrote:Je n’ai jamais entendu dire qu’il y avait une limite de mémoire, et s’il y en avait une elle empêcherait aussi de swapper à mon avis. Pour ma part je te confirme avoir déjà dépassé allègrement les 256Mo sans préciser d’option.
J'ai lu ça dans différentes pages du wiki d'openstreetmap. Par exemple ici et là, mais je n'ai jamais cherché plus loins l'étendue de cette option.

Pardon, je pensais que tu parlais de la limite au niveau système. Au niveau de la JVM, il y a bien une limite, mais apparemment dans les dernières versions cette limite vaut le quart de la mémoire disponible, dans la limite de 1 gigot. Si tu veux connaître la valeur par défaut chez toi, fais

java -XX:+PrintFlagsFinal -version | grep MaxHeapSize

(le résultat est en octets visiblement).

Kypso wrote:Mon edit un peu plus haut est peu être passé inaperçu. J'ai désacivé l'hyper threading dans le Bios (processeur Core i7) et tout est rentré dans l'ordre.

Non non, je n’ai rien raté. Hyperthreading ou pas, un PC qui freeze n’est pas normal. L’hyperthreading est une fonctionnalité intéressante, alors je trouve dommage d’être obligé de s’en priver.

Kypso

WilQu wrote: Pardon, je pensais que tu parlais de la limite au niveau système. Au niveau de la JVM, il y a bien une limite, mais apparemment dans les dernières versions cette limite vaut le quart de la mémoire disponible, dans la limite de 1 gigot. Si tu veux connaître la valeur par défaut chez toi, fais
java -XX:+PrintFlagsFinal -version | grep MaxHeapSize
(le résultat est en octets visiblement).

Voila ce que ca donne chez moi:
uintx MaxHeapSize := 1564475392 {product}

WilQu wrote: Non non, je n’ai rien raté. Hyperthreading ou pas, un PC qui freeze n’est pas normal. L’hyperthreading est une fonctionnalité intéressante, alors je trouve dommage d’être obligé de s’en priver.

C'est certain. J'ai ouvert un bug sur bugzilla car je n'ai pas trouvé de problème similaire.
http://bugzilla.redhat.com/show_bug.cgi?id=819345