Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre du Club
    Inscrit en
    septembre 2005
    Messages
    193
    Détails du profil
    Informations forums :
    Inscription : septembre 2005
    Messages : 193
    Points : 47
    Points
    47

    Par défaut Difference de performances Unix/Windows d'un programme?

    Bonjour,
    J'ai une interface qui tourne sur un serveur de prod dont les indicateurs (top sous Unix à 2.0 max) sont bons et pourtant j'ai des perfs lamentables autour de 10h de traitement.
    Cette même interface met 3h30 à 4h sous windows sachant que je l'ai developpée sous et compilé sous Windows/Eclipse.

  2. #2
    Inactif  
    Profil pro
    Inscrit en
    mai 2006
    Messages
    2 189
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : Suisse

    Informations forums :
    Inscription : mai 2006
    Messages : 2 189
    Points : 2 272
    Points
    2 272

    Par défaut

    Etonnant,

    Quel type de traitement ton programme fait ?

    Quels programmes utilisent-t-il ?

  3. #3
    Membre expert
    Avatar de natha
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    2 346
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : janvier 2006
    Messages : 2 346
    Points : 3 083
    Points
    3 083

    Par défaut

    Quelles librairies natives sont utilisées ?
    Car peut-être que tu utilises des librairies nulles en Unix et quelles sont bonnes en Windows.

    Il faut plus d'infos détaillées pour qu'on puisse répondre à ce genre de question.
    Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
    De la bonne manière de poser une question (et de répondre).
    Je ne fais pas de service par MP. Merci (...de lire les règles...).
    Ma page dvp.com

  4. #4
    Membre du Club
    Inscrit en
    septembre 2005
    Messages
    193
    Détails du profil
    Informations forums :
    Inscription : septembre 2005
    Messages : 193
    Points : 47
    Points
    47

    Par défaut

    Au fait, j'ai passé hier à potasser la doc GC.
    Le problème ne vient pas de l'OS mais du serveur sur lequel , je fais tourner l'interface (qui fait du traitement via une API d'un progiciel).
    En effet sur le serveur de Prod: (Unix)
    Full GC dure de 5 à 6 sec
    Sur le Serveur de Dev (Unix)
    Full GC dure de 1 à 2 sec
    Etant donné que l'interface est pas super bien codé notamment avec des appels explicité à system.gc() toutes les iterations , je vous laisse imaginer la degradation de perf...
    Je suis en train de tenter :
    -XX:+DisableExplicitGC
    Pour desactiver les appels à system.gc()...

    Si vous avez des idees...
    (la memoire free est de 1800 Mo sur les 2 serveurs et 9G de free Swap)
    Le Top donne un bon load average qui depasse pas les 2

    J'attend vos conseils d'optimisation

    Voila

  5. #5
    Membre expert
    Avatar de natha
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    2 346
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : janvier 2006
    Messages : 2 346
    Points : 3 083
    Points
    3 083

    Par défaut

    Citation Envoyé par petozak
    Etant donné que l'interface est pas super bien codé notamment avec des appels explicité à system.gc() toutes les iterations
    Oula d'accord, je comprends mieux ! Genre le truc à pas faire par excellence
    Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
    De la bonne manière de poser une question (et de répondre).
    Je ne fais pas de service par MP. Merci (...de lire les règles...).
    Ma page dvp.com

  6. #6
    Membre du Club
    Inscrit en
    septembre 2005
    Messages
    193
    Détails du profil
    Informations forums :
    Inscription : septembre 2005
    Messages : 193
    Points : 47
    Points
    47

    Par défaut

    Citation Envoyé par natha
    Oula d'accord, je comprends mieux ! Genre le truc à pas faire par excellence

    Je plaide innoncent... je ne l'ai pas fait .
    Moi je tente d'optimiser...

  7. #7
    Membre expert
    Avatar de natha
    Profil pro
    Inscrit en
    janvier 2006
    Messages
    2 346
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : janvier 2006
    Messages : 2 346
    Points : 3 083
    Points
    3 083

    Par défaut

    Citation Envoyé par petozak
    Je plaide innoncent... je ne l'ai pas fait .
    Moi je tente d'optimiser...
    Bah déjà faut tous les virer ces appels GC, vérifie également que tu tournes sur une JVM en mode serveur et teste voir si ça améliore.
    Accessoirement surveille la consommation mémoire de ton applic pendant le test (si tu utilises java5 ou plus tu as jconsole qui est bien pratique ma foi).

    Après on ne peut pas vraiment te dire comment optimiser... faut plus de détails. On n'est pas magiciens.
    Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
    De la bonne manière de poser une question (et de répondre).
    Je ne fais pas de service par MP. Merci (...de lire les règles...).
    Ma page dvp.com

  8. #8
    Membre du Club
    Inscrit en
    septembre 2005
    Messages
    193
    Détails du profil
    Informations forums :
    Inscription : septembre 2005
    Messages : 193
    Points : 47
    Points
    47

    Par défaut

    Bon bonne nouvelle , je passe d'un temps traitement de 10h à 2h waw!!
    Sans les Full GC c'est genial...par contre mon me tanne pour savoir pourquoi les Full GC sont aussi long sur notre serveur de prod...
    d'ou ca peut venir?
    (On est en "1.4.2_06" alors qu'en dev , on est en 1.5_11 mais bon ca n'explique pas pour moi)

  9. #9
    Expert éminent sénior
    Avatar de sinok
    Profil pro
    Inscrit en
    août 2004
    Messages
    8 765
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : août 2004
    Messages : 8 765
    Points : 12 917
    Points
    12 917

    Par défaut

    Euh vu les diffs de perfs entre la 1.4 et la 1.5 c'est compréhensible (d'ailleurs c'est pas forcément une bonne idée de travailler avec des versions diffférentes entre les environnements de prod et de dev).

    Et le GC est une bestiole qui peut te bouffer un bon paquet de mêmoire les temps de vérifier toutes les références. D'autant plus que tu ne gères pas réellement le moment ou il intervient. Mieux vaut ne pas trop l'emmerder et le laisser faire tranquillement son boulot dans son coin
    Hey, this is mine. That's mine. All this is mine. I'm claiming all this as mine. Except that bit. I don't want that bit. But all the rest of this is mine. Hey, this has been a really good day. I've eaten five times, I've slept six times, and I've made a lot of things mine. Tomorrow, I'm gonna see if I can't have sex with something.

  10. #10
    Membre du Club
    Inscrit en
    septembre 2005
    Messages
    193
    Détails du profil
    Informations forums :
    Inscription : septembre 2005
    Messages : 193
    Points : 47
    Points
    47

    Par défaut

    Citation Envoyé par sinok
    Euh vu les diffs de perfs entre la 1.4 et la 1.5 c'est compréhensible (d'ailleurs c'est pas forcément une bonne idée de travailler avec des versions diffférentes entre les environnements de prod et de dev).

    Tu crois vraiment que sun a reussi à gagner autant au niveau des system.gc() (full gc)?
    C'est aussi revolutionnaire que ca la 1.5?

  11. #11
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 930
    Points : 22 979
    Points
    22 979
    Billets dans le blog
    1

    Par défaut

    Salut,

    Citation Envoyé par petozak
    Bon bonne nouvelle , je passe d'un temps traitement de 10h à 2h waw!!
    Sans les Full GC c'est genial...par contre mon me tanne pour savoir pourquoi les Full GC sont aussi long sur notre serveur de prod...
    d'ou ca peut venir?
    (On est en "1.4.2_06" alors qu'en dev , on est en 1.5_11 mais bon ca n'explique pas pour moi)
    Je dirais que c'est parce que le GC fait bien son boulot tout seul... en libérant la mémoire quand il le faut. Pour cela il utilise deux types de libérations les minors collections et les majors collections (bien plus gourmande en temps). Pour plus d'info : http://gfx.developpez.com/tutoriel/java/gc/


    En appelant explicitement System.gc() on le force à faire le ménage... ce qui peut être pénalisant !


    Un exemple : la création de 50000 objets dans un boucle :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    	System.out.println("START");
    	for (int i = 50000; i>0; i--) {
    		Object o = new Object();
    	}
    	System.out.println("END");
    Lorsque j'exécute ce code avec l'option -verboce:gc de la JVM (ce qui permet de logger le passage du GC), j'obtiens ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    START
    [GC 512K->102K(1984K), 0.0080338 secs]
    END
    Le GC effectue seulement une minor collection qui dure environ 8 millisecondes, et fait descendre la mémoire de 512K à 102k. Le programme s'exécute en quelques ms...



    Maintenant si je force le passage du GC à chaque itération :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    	System.out.println("START");	
    	for (int i = 50000; i>0; i--) {
    		Object o = new Object();
    		System.gc();
    	}
    	System.out.println("END");
    J'obtiens ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    START
    [Full GC 148K->102K(1984K), 0.0420998 secs]
    [Full GC 102K->102K(1984K), 0.0406980 secs]
    [Full GC 102K->102K(1984K), 0.0422317 secs]
    [Full GC 102K->102K(1984K), 0.0385216 secs]
    [Full GC 102K->102K(1984K), 0.0447407 secs]
    (...)
    J'ai bien sûr tronqué le résultat, car le programme est très long (et je n'ai pas eu le courage d'attendre jusqu'à la fin... En fait il y a une major collection (Full GC) à chaque itération... et chaque "Full GC" prend environ 40ms... Si on calcule bien au final cela représente plus de 30 minutes !!!

    Tout cela pour libérer un seul objet ! Le problème est que les "Full GC" sont bien plus couteux, et qu'ils sont appelés inutilement...


    Bref : System.gc() est vraiment à utiliser dans des cas très rare, et surtout pas dans une boucle !!!



    Quand à la différence entre le serveur de dev et de prod, cela vient surement du fait que le System.gc() n'est pas forcément exécuté. Ce n'est qu'une suggestion et la JVM peut l'ignoré (Utilise -verboce:gc pour vérifier cela -- attention car ceci peut être couteux car cela génère de gros logs).


    a++

  12. #12
    Membre du Club
    Inscrit en
    septembre 2005
    Messages
    193
    Détails du profil
    Informations forums :
    Inscription : septembre 2005
    Messages : 193
    Points : 47
    Points
    47

    Par défaut

    Citation Envoyé par adiGuba
    Salut,



    Je dirais que c'est parce que le GC fait bien son boulot tout seul... en libérant la mémoire quand il le faut. Pour cela il utilise deux types de libérations les minors collections et les majors collections (bien plus gourmande en temps). Pour plus d'info : http://gfx.developpez.com/tutoriel/java/gc/


    En appelant explicitement System.gc() on le force à faire le ménage... ce qui peut être pénalisant !


    Un exemple : la création de 50000 objets dans un boucle :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    	System.out.println("START");
    	for (int i = 50000; i>0; i--) {
    		Object o = new Object();
    	}
    	System.out.println("END");
    Lorsque j'exécute ce code avec l'option -verboce:gc de la JVM (ce qui permet de logger le passage du GC), j'obtiens ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    START
    [GC 512K->102K(1984K), 0.0080338 secs]
    END
    Le GC effectue seulement une minor collection qui dure environ 8 millisecondes, et fait descendre la mémoire de 512K à 102k. Le programme s'exécute en quelques ms...



    Maintenant si je force le passage du GC à chaque itération :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    	System.out.println("START");	
    	for (int i = 50000; i>0; i--) {
    		Object o = new Object();
    		System.gc();
    	}
    	System.out.println("END");
    J'obtiens ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    START
    [Full GC 148K->102K(1984K), 0.0420998 secs]
    [Full GC 102K->102K(1984K), 0.0406980 secs]
    [Full GC 102K->102K(1984K), 0.0422317 secs]
    [Full GC 102K->102K(1984K), 0.0385216 secs]
    [Full GC 102K->102K(1984K), 0.0447407 secs]
    (...)
    J'ai bien sûr tronqué le résultat, car le programme est très long (et je n'ai pas eu le courage d'attendre jusqu'à la fin... En fait il y a une major collection (Full GC) à chaque itération... et chaque "Full GC" prend environ 40ms... Si on calcule bien au final cela représente plus de 30 minutes !!!

    Tout cela pour libérer un seul objet ! Le problème est que les "Full GC" sont bien plus couteux, et qu'ils sont appelés inutilement...


    Bref : System.gc() est vraiment à utiliser dans des cas très rare, et surtout pas dans une boucle !!!



    Quand à la différence entre le serveur de dev et de prod, cela vient surement du fait que le System.gc() n'est pas forcément exécuté. Ce n'est qu'une suggestion et la JVM peut l'ignoré (Utilise -verboce:gc pour vérifier cela -- attention car ceci peut être couteux car cela génère de gros logs).


    a++


    Merci c'est tres instructif.
    Et sinon la jvm 1.5 est elle à ce point plus performante que la 1.4 pour le Full GC?

  13. #13
    Membre du Club
    Inscrit en
    septembre 2005
    Messages
    193
    Détails du profil
    Informations forums :
    Inscription : septembre 2005
    Messages : 193
    Points : 47
    Points
    47

    Par défaut

    Au fait j'utilise verbose , sinon je pourrai vous dire les temps des FGC ...
    Apparement la jvm 1.5 gere bien mieux les major collection.

  14. #14
    Gfx
    Gfx est déconnecté
    Expert éminent
    Avatar de Gfx
    Inscrit en
    mai 2005
    Messages
    1 770
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : mai 2005
    Messages : 1 770
    Points : 8 178
    Points
    8 178

    Par défaut

    La JVM 1.5 a apporté pas mal d'améliorations au GC, elle en vaut largement la peine. Il est également intéressant de bien comprendre comment le GC fait son travail et surtout quels algorithmes de GC sont disponibles et comment les paramétrer. Cela va bien plus loin que le choix entre la JVM server et client (qui interviennent plus sur le JIT en fait). En outre, le paramétrage du GC doit vraiment se faire au cas par cas. Cela dépend donc vraiment de ton application (crée-t'elle beaucoup d'objets temporaires ? beaucoup d'objets avec une longue durée de vie ? etc.) et du hardware (un ou plusieurs CPU ? combien de RAM ? etc.).

    Si tu tournes avec J2SE 1.5, essaye très vite l'outil jconsole qui te permet d'observer le comportement du GC. Sinon, tu peux faire comme dans mon article et écrire des scripts pour analyser les traces du GC et créer des graphes sous OpenOffice.org/Excel pour voir un peu mieux ce qu'il se passe.

    Une chose est sûre, il *faut* supprimer tous ces appels à System.gc(). Souviens-toi que le GC interrompt l'exécution de l'application.

    Je te conseille également d'utiliser un bon profiler (cf celui de NetBeans ou jconsole) pour vérifier que vous ne leakez pas de la mémoire dans le tenured space. Cela pourrait expliquer la lenteur des major collections. Des appels à gc() n'arrangeront en rien les choses, ou seulement temporairement.
    Romain Guy
    Android - Mon livre - Mon blog

  15. #15
    Membre du Club
    Inscrit en
    septembre 2005
    Messages
    193
    Détails du profil
    Informations forums :
    Inscription : septembre 2005
    Messages : 193
    Points : 47
    Points
    47

    Par défaut

    Merci GFX.
    J'ai récupéré les temps totaux squattés par le GC est finalement je passe de 16 min à 1min42 apres avoir tweaker à mon amximum la Jvm.
    Le temps d'execution est tres long (tres gros objets à exporter)...je vais essayer de tweaker hibernate ou au mieux améliorer l'algo.
    Merci à Tous.
    Un post plus qu'instructif

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Solution de communication haut niveau Unix/Windows
    Par mi6fred dans le forum Développement
    Réponses: 2
    Dernier message: 05/05/2006, 20h11
  2. difference d'affichage selon windows XP
    Par firejocker dans le forum MFC
    Réponses: 9
    Dernier message: 03/02/2006, 18h24
  3. Conversion d'une chaine Unix -> windows ?
    Par sber74 dans le forum C
    Réponses: 8
    Dernier message: 01/02/2006, 15h51
  4. Code source commun Unix/Windows
    Par scorian dans le forum C++
    Réponses: 17
    Dernier message: 08/12/2004, 14h37
  5. probleme portage Unix --> Windows
    Par casier dans le forum MFC
    Réponses: 5
    Dernier message: 22/01/2004, 21h12

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo