Discussion :

[lr]

Salut,

Je dois récupérer les données d'une table qui contient plusieurs centaines de milliers de lignes afin de générer des rapports.

Le problème c'est que j'obtiens systématiquement des OutOfMemoryError.

Comment traîter ce problème ?

J'ai essayé ça mais ça ne change rien :

Code :

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

1
2
3
PreparedStatement statement = connection.prepareStatement( query, ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_READ_ONLY );
statement.setFetchSize( 1000 );
ResultSet resultSet = statement.executeQuery();

Merci d'avance
Lilian

[in]

à mon avis le problème mémoire ne vient pas de la requete mais du stockage des résultats ...

tu as mis un paramètre relatif à la mémoire pour le lancement (xms, xmx ?). Dans le cas contraire la mémoire utilisée pas java est 64 Mo je crois, donc si tu peux en mettre plus ...

[lr]

à mon avis le problème mémoire ne vient pas de la requete mais du stockage des résultats ...

tu as mis un paramètre relatif à la mémoire pour le lancement (xms, xmx ?). Dans le cas contraire la mémoire utilisée pas java est 64 Mo je crois, donc si tu peux en mettre plus ...

Merci pour ta réponse,

Effectivement ça vient du stockage en mémoire du résultat du select. En tout cas c'est mon impression.

Mais je doute que la solution soit d'augmenter la mémoire alloué à la VM car cette mémoire n'est pas infinie alors que le nombre de lignes de ma table...

Il me faudrait une vraie solution, je pourrais faire de la pagination en ajoutant des LIMIT et OFFSET à ma requête mais je préfèrerais éviter, je me dis que ça doit être une problématique classique et qu'il doit y avoir des solutions...

[in]

a mon avis si tu veux vraiment stocker "plusieurs centaines de milliers de lignes" en mémoire, il va falloir l'augmenter. Ya rien de choquant.

Ensuite comment stockes tu ces données (arbre, liste ordonnée ....) ça peut jouer pas mal. Ainsi que ce que représente une ligne ... si t'as des blob et des gros textes, c'est pas gagné.

Si tu ne veux pas augmenter la mémoire, tu n'as pas d'autre solution que de traiter morceaux par morceaux.

Y'a pas d'autre solution je pense. Et pour moi c'est une "vraie" solution
Qu'est ce que ce serait pour toi une "vraie" solution ?

[lr]

Je ne souhaite pas particulièrement les stocker en mémoire, j'ai juste besoin de pouvoir faire

Code :

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

statement.executeQuery()

puis des

Code :

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

resultset.next()

etc.

Avec ça je génère des PDF que j'écris sur le disque, je ne devrais pas avoir à tout stocker.

Mais je ne sais pas comment c'est implémenté dans java.sql, donc je ne sais pas si tout le résultat de la requête est stocké ou si les données sont récupérées au fur et à mesure que j'avance mon curseur avec next().

Je suis en train d'essayer en paginant en ajoutant des LIMIT et OFFSET à ma requête mais j'ai l'impression que je ne devrais pas avoir à faire ça

[in]

Mais je ne sais pas comment c'est implémenté dans java.sql, donc je ne sais pas si tout le résultat de la requête est stocké ou si les données sont récupérées au fur et à mesure que j'avance mon curseur avec next().

en fait tout n'est pas rapatrié d'un coup. Tu as une fetchsize qui est définie. Elle indique le nombre de lignes rapatriées par le ResultSet. Lors de l'appel à next sur la dernière ligne, il te rapatrie les suivantes. Tu peux essayer de le baisser pour voir si c'est mieux, ça va réduire la taille de l'objet ResultSet en mémoire.

Ton problème de mémoire vient peut être de la création du fichier pdf ? as tu essayer d'utiliser un outil de profilage pour suivre l'évolution de la conso mémoire ?

[CyberChouan]

Est ce qu'effectuer ta requête par parties pourrait résoudre ton problème? (je ne sais pas ce que tu fais de tes données derrière ta requête)

Dans ce cas, tu devrais peut-être exécuter ta requête par morceaux pour ne garder que 100 (ou 1000) résultats à la fois: dans ce cas, c'est sur le mot-clé LIMIT de ta requête SQL que tu dois te renseigner

EDIT: Oups, je n'avais pas vu que tu étudiais déjà cette solution.

Pour moi, il n'y a rien de choquant à effectuer une grosse requête en plusieurs parties en utilisant LIMIT si on ne peut pas tout traiter d'un coup

[chtig]

Effectivement aucun souci à traiter par partie ... En revanche, utiliser un LIMIT, bof bof question portabilité de base .. Lui préférer les size Java... Mais apparemment tu as essayé et ça ne fonctionnait pas ?

[lr]

Je ne comprend vraiment pas pourquoi ce code me donne une OutOfMemoryError.

Comme vous l'avez dit, si le nombre de lignes est très important, tout n'est pas retiré en une fois, mais au fur et à mesure des resultset.next() donc je ne comprend pas... Une mauvaise implémentation du driver jdbc peut-être ???

Pour info il s'agit de postgresql-8.1-407.jdbc3.jar

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
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
 
import com.dotbase.jasper.configuration.Configuration;
 
 
public class TestQuery
{
	static Connection jdbcConnection = null;
 
	public static void main( String args[] ) throws Exception
	{
		Class.forName( Configuration.getParameter("database.driver") );
		jdbcConnection = DriverManager.getConnection("jdbc:postgresql://dbserver:5432/dbName", "username", "password");
 
 
		String query = "Select * from t_tiers";
 
		PreparedStatement statement = jdbcConnection.prepareStatement( query );
		statement.setFetchSize( 100 );
		ResultSet rsReportData = statement.executeQuery();
	}
}

[chtig]

Exact à vérifier (recherche sur ce forum car déjà vu ça) mais il me semble que le driver postgres ne supporte pas les fetch size ....

[lr]

Exact à vérifier (recherche sur ce forum car déjà vu ça) mais il me semble que le driver postgres ne supporte pas les fetch size ....

Et donc il récupérerait tout en mémoire ? Pas terrible...

Je continue à chercher.

[lr]

Avec ce code ça semble marcher (piste trouvée sur http://jdbc.postgresql.org/documenta...ry-with-cursor) :

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
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
 
import com.dotbase.jasper.configuration.Configuration;
 
 
public class TestQuery
{
	static Connection jdbcConnection = null;
 
	public static void main( String args[] ) throws Exception
	{
		Class.forName( Configuration.getParameter("database.driver") );
		jdbcConnection = DriverManager.getConnection("jdbc:postgresql://dbserver:5432/dbname", "username", "password");
 
		String query = "Select * from t_tiers";		
 
 
 
		jdbcConnection.setAutoCommit( false );
 
 
		PreparedStatement statement = jdbcConnection.prepareStatement( query );//, ResultSet.TYPE_FORWARD_ONLY, java.sql.ResultSet.CONCUR_READ_ONLY );
		statement.setFetchSize( 100 );
		ResultSet rsReportData = statement.executeQuery();
	}
}

[chtig]

En fait ça marche sur les PreparedStatement et pas sur les Statement ?

[lr]

En fait ça marche sur les PreparedStatement et pas sur les Statement ?

Il faudrait vérifier. Moi je seulement eu a ajouter

Code :

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

jdbcConnection.setAutoCommit( false );

et

Code :

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

statement.setFetchSize( 100 );

[chtig]

Ah ben non j'avais mal lu mais dès le début tu utilisais un Prepared. Le setFetchSize aussi ...
Donc la seule chose que tu as changée c'est le autocommit ???

[lr]

Ah ben non j'avais mal lu mais dès le début tu utilisais un Prepared. Le setFetchSize aussi ...
Donc la seule chose que tu as changée c'est le autocommit ???

Oui, et j'ai lancé le code avec et sans le autocommit et c'est clair que c'est ça.

[chtig]

Alors faudrait qu'on m'explique, parce que je ne vois pas du tout le rapport... Pour moi c'est clairement un bug du driver non ?

[lr]

Alors faudrait qu'on m'explique, parce que je ne vois pas du tout le rapport... Pour moi c'est clairement un bug du driver non ?

Je ne suis pas suffisamment expert pour l'affirmer, mais c'est également ce que je pense