Discussion :

[chrass]

Bonjour tout le monde

voila après 2 mois de travail à modéliser un DWH et de créer des jobs pour l'alimenter , j'arrive à l'étape de l'industrialisation et boom un choc

j'ai crée 32 job pour alimenter l’entrepôt, qui fera un traitement sur plusieurs tables( qui fera en total plus de 150 millions de lignes )

j'ai créé un job qui regroupe le tout et je l'ai exporté en .bat

quand je lance le .bat j'ai toujours un java heap space après quelque heure de traitement

je suis sur un pc 32 bit donc je peux pas dépasser 1700 Mo de ram
j'ai même essayé d’exécuter job par job et toujours le même problème la mémoire se sature pourtant j'ai 3 Go de mémoire

qu'est ce que je dois faire ?? je suis vraiment perdu

Cordialement

[kojuo]

Bonjour,

C'est simple, il faut débugger

Utiliser un outil de profiling mémoire (jvisualvm.exe, fournit avec la JDK est très bien pour ça ; en complément, si tu utilises beaucoup de fichiers, ProcessExplorer pour visualiser la charge de lecture/écriture du disque) te permettra de mieux identifier la source du problème et de préciser sa résolution.

En fonction du résultat de ces analyses, il te faudra éventuellement revoir l'architecture du ou des jobs concernés pour mieux utiliser les ressources de ta machine.


Julien

[chrass]

Merci c'est gentil pour ta réponse
je vais essayé cela , mais je me pose une question , y a t'il pas moyen de vider le garbage collector automatiquement , parce que on dirait que java ne le fait pas automatiquement

le souci c'est que je suis en 32 bit et je peux pas augmenter la taille de la mémoire max pour le traitement !!

[kojuo]

Le Garbage Collector tourne de lui même en "continu".
Il sert à débarasser la mémoire des objets obsolètes... mais encore faut-il qu'ils soient considérés comme tel !
C'est pour cela qu'il te faut analyser les causes de ta surcharge de mémoire.

Le problème ne vient pas du GC ni de java, mais de l'architecture de ton job.
Augmenter la mémoire utilisable n'est pas une solution pérenne dans ce genre de situation, il vaut mieux réfléchir à l'usage que tu fais de la mémoire et à l'optimisation que tu peux réaliser sur ce point.


Julien

[chrass]

d'accord j'ai bien compris , mais j'utilise des job optimisé ( à mon avis ) je pense le souci vient du fait que j'ai des tables avec des millions de ligne

qu'est que t'en pense ?

[kojuo]

d'accord j'ai bien compris , mais j'utilise des job optimisé ( à mon avis ) je pense le souci vient du fait que j'ai des tables avec des millions de ligne

qu'est que t'en pense ?

Pas par rapport à tes contraintes matérielles, apparemment !

[chrass]

oui je pense, de toute façon ou je travaille, ils ne veulent pas acheter du matériel puissant.

et c'est la le plus grand dilemme, je ne sais vraiment pas ce que je dois faire.

et en plus de cela le traitement peut durer plus de 25 heures et ils veulent que ça tient en une nuit !!

[kojuo]

Un profiling mémoire serait un bon point de départ

[chrass]

ben je l'ai fait, la mémoire utilisé monte mais je peut pas rester 25 heures pour la surveiller

après quand je clique sur le GC ben la mémoire utilisé baisse énormément et ca doit soulager

après je sais pas , je t'informe que j'ai plus de 30 jobs et ça traite en total plus de 300 millions de lignes !!!

[Benoit_Durand]

Il faudrait avoir un screenshot du job qui bouffe toute la mémoire.

Après un conseil pour les grosse volumétrie : SQL c'est facile, c'est fait pour traiter des données et ça sait le faire, Java n'est pas fait pour traiter des données. il faut passer un maximum de taf sur le SGBD, ne pas faire de jointure en java sur sur de grosses volumétries.

Autre point, les alimentations traitent 300 millions de lignes par jour, au final dans les tables de faits de l'entrepôt il y a combien de lignes ?

[chrass]

ben en fait j'ai des tables dans un ODS avec un historique de 3 mois et je dois créer un entrepôt avec les donnée mais avec un historique et de cet entrepôt je fais l'agrégation sur une année.
donc pour chaque table de l'ODS j'ai 2 tables dans l’entrepôt

en pièce jointe un job parmi 30 job , mais c'est presque la même chose


Merci de votre aide

[Benoit_Durand]

ouch !

Pour les tUniqRow il faut cocher la case "utiliser le disque".
Et comme je le signalais plus tôt je conseille de ne pas faire de jointure dans les tMap lorsqu'il y a de fortes volumétrie (>500k en look up). Il vaut mieux essayer de tout charger dans des tables de la même base, ajouter des indexs et ensuite faire des requêtes SQL avec des jointures, ce sera beaucoup plus performant et pas de problème de JVM.

[chrass]

Merci pour ta réponse , mais l'interet c"est que j'exporte tout les jobs en .bat , si j'utilise le traitement sur disque il va le prendre en considération quand je l'exporte afin d'etre executer sur une autre machine ?

[Benoit_Durand]

oui, pour ça il est préférable de faire une variable de contexte context.monRep et de lui indiquer cette variable dans le chemin.
Lors de l'export sur un autre environnement il sera possible de lui indiquer un autre répertoire. (voir les autres posts sur ce sujet)

[chrass]

ahhh d'accord , je savais pas qu'on peut faire comme ca !!!

merci c'est gentil de ta part , je dormirai moins con ce soir


c'est résolu le problème