Discussion :

[cepekinio]

Bonjour,

Je rencontre depuis peu un problème très bloquant avec JPA et la mémoire.
En effet, je dois parcourir une liste d'entités et créer à partir de chaque entité un fichier XML que je stocke sur le disque dur.

Hors, je me rends compte que, a chaque passage dans ma boucle, ma mémoire prends quelques Mo supplémentaire et, malgré le passage du GC, ces quelques Mo ne sont jamais libéré. Après 20/25 passages dans la boucle j'arrive a plus de 500Mo de mémoire et la bah HeapSpace......

Après avoir analysé la mémoire, je me rends compte que l'ensemble des entités sont gardées en mémoire (encore utilisée ou non).

Je n'utilise pas de transactions, ni de commit ou autre car je prends juste une entité a chaque boucle pour la parcourir et créer directement mon fichier XML.

Quelqu'un a t il une solution pour libérer l'espace mémoire occupé par une entité JPA ??

[DevServlet]

Effectivement c enorme l'espace mémoire occupé, combien forment en moyen les tailles de fichiers xmls generés? essaie de passer à null les entités juste après leur usage, pour faciliter le boulot du GC, mais bon n'empêche que le pb doit venir ailleurs.

[cepekinio]

J'ai bien pensé aussi que le soucis venait d'ailleurs.
Je prends bien chaque entité et je la met à null une fois que j'en ai plus besoin.
Mais rien n'y fait et la mémoire grimpe toujours autant.....
J'ai donc pris la peine d'analyser la mémoire avec un outil dédié et les seuls objets encore présent dans la mémoire sont les entités (aucunes n'a été supprimées par le GC).

Mes fichier XML font entre 500ko et 10Mo (pouvant contenir + de 200 000 lignes).

Le tout correspond à une procédure d'exportation de données de ma base vers ces fichiers XML.
Hors quand je réalise le même genre de manipulation mais cette fois pour l'importation des données, la pas de soucis de ce genre (en veillant a mettre mes objets a null etc ).

Je suis totalement bloqué et je ne sais vraiment plus quoi faire (2 jours complet de taff pour rien ).

Merci pr ta réponse!

[cepekinio]

Petite précision :

J'ai remarqué que je n'étais pas le seul a avoir se problème. En effet, mon collègue rencontre également se phénomène (a une moindre mesure) lorsqu'il instancie un objet de type entité JPA et qu'il le parcours. L'espace mémoire occupé pour la lecture de l'objet n'est jamais libéré même si l'entité qu'il vient de parcourir est mise à null une fois la lecture réalisée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Exemple :
//Client = Entité JPA correspondant à une table Client de ma base
Client toto = new Client();
 
afficher(toto.getName);
afficher(toto.getAdresse);
afficher(toto.getGenre);
for(Fils f : toto.getListFils)
{
     afficher(f.getName);
}
 
toto = null;

Voila un exemple mais si je veux faire ca pour tt les client la mémoire augmente de quelques Mo a chaque fois.

[thebloodyman]

Bonsoir,

Je n'utilise pas de transactions, ni de commit ou autre car je prends juste une entité a chaque boucle pour la parcourir et créer directement mon fichier XML.

Mais tu fais bien des appels en base, non ?

Si c'est le cas :
je ne connais pas trop Toplink, mais ca serait pas lui qui utiliserait un cache de second niveau pour tes entités ?

L'espace mémoire occupé pour la lecture de l'objet n'est jamais libéré même si l'entité qu'il vient de parcourir est mise à null une fois la lecture réalisée.

Tu dois sûrement le savoir mais c'est parce que tu mets un objet à null qu'il est forcément supprimé par le GC.
Si ton objet entité reste référencé par un autre objet non éligible au nettoyage du GC, le GC ne le supprimera pas.

Le tout correspond à une procédure d'exportation de données de ma base vers ces fichiers XML.
Hors quand je réalise le même genre de manipulation mais cette fois pour l'importation des données, la pas de soucis de ce genre (en veillant a mettre mes objets a null etc ).

Dans l'autre sens (xml-> bdd), tu n'utilises pas de cache dans la couche persistance puisque tu fais que des insertions. La piste du cache de second niveau reste plausible.

Je viens de jeter un coup d'oeil sur le net et il se trouve qu'au moins une des implémentations de Toplink utilisent le cache de second niveau par défaut : http://weblogs.java.net/blog/guruwon...nding_t_1.html

La phrase intéressante

Session cache is turned on by default so you can use it now without any extra configuration. With this 2nd-level cache you can get performance benefits.

Le site propose des solutions pour désactiver le cache.

Sinon, j'avais une petite question : vous utilisez toplink pour des raisons particulières ?

[cepekinio]

Merci pour ta réponse !
Effecitvement je fais des appels en base puisque je récupère une liste d'entités, que je parcours ensuite et pour chacunes, je vais lire les valeurs, récupérer les listes de fils, de petit fils etc etc etc

Le cache L2 de EclipseLink ou TopLink est bien activé par défaut mais je viens de le désactiver et rien n'y fait....toujours le même soucis.

J'ai commenté l'ensemble du code qui ne concernait pas directement la lecture des entités JPA et le problème persiste donc je suis maintenant plus que certain que le soucis viens bien de la.

Il y a t il un moyen de visualiser en temps réel la taille des caches utilisés par JPA ?

Merci d'avance

[cepekinio]

J'ai réalisé un petit code de test qui parcour juste quelques unes des entités pour voir.
Je précise qu'il n'y a que cela qui tourne !!!

Voici le résultat :
Code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
public class TestJpa
{
	public static void main(String[] args){
		PersistenceService manager = PersistenceService.getInstance();
		SQLUtil connect = new SQLUtil("root", "");
		if (connect.getResult())
		{
			manager.initialize(connect.getMap());
		}
 
		List<Baselineinfo> lBlis = (List<Baselineinfo>)manager.getResultListNamed("Baselineinfo.findAll");
 
		for(Baselineinfo bli : lBlis)
		{
			ddd(bli);
		}
 
	}
 
	public static void ddd(Baselineinfo _bli)
	{
		System.out.println("BLI : "+_bli.getBliTitle());
		for(Dfi dfi : _bli.getDfiList())
		{
			System.out.println("DFI : " + dfi.getDfiDfi());
			for(Dui dui : dfi.getDuiList())
			{
				System.out.println("DUI : " + dui.getDuiDui());
				for(Enumerate enums : dui.getEnumerateList())
				{
					System.out.println("Enum : "+enums.getEnmMin()+"-"+enums.getEnmMax());
					enums = null;
				}
				dui = null;
			}
			dfi = null;
		}
	}
}

extrait du persistence.xml :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<shared-cache-mode>NONE</shared-cache-mode>
<properties>
<property name="eclipselink.cache.shared.default" value="false"/>
<property name="eclipselink.query-results-cache" value="false"/>
</properties>

et visualisation de la mémoire (attention les yeux !!!) :

[fr1man]

Surement ton cache de premier niveau qui sature.
Utilise la méthode clear de ton EntityManager pour le vider, ou remove pour détacher tes entités.