Discussion :

[donnadieujulien]

Bonjour, je réalise un programme assez lourd.

Je suis en phase d'optimisation.

En fait, ce programme travaille avec des tables de données DB2 assez lourdes (pluisieurs millions de lignes), les interfaces sont elles aussi assez lourde et la mémoire alloué fait parfois défaut.

Mon problème consiste à éviter au maximum les erreurs de type JAva Heap Space.

Pour l'instant, je fai un test de mémoire en amont pour avoir la mémoire disponible, et je compare à un tableau de valeur que je me suis crée.

Par exemple, si on veut sortir 50000 lignes d'une table, j'ai mis la case du tableau à 5Mo.

Mais cette méthode n'est pas très efficace, et je chercherai à l'optimiser.

Je ne peux pas "bloquer" l'affichage/mise en mémoire au delà d'un certain nombre (50 000 serait bien) car cela impacte l'utilité du matériel. Il faut que l'utilisateur puisse afficher 200 000 lignes s'il le souhaite...

J'ai remarqué qu'en chargeant petit à petit (appui sur un bouton pour rajouter X lignes) marche mieux qu'en chargeant out d'un coup, pourquoi??

Franchement, je ne vois pas comment faire, car ce test de mémoire n'est vraiment pas efficace.

[tchize_]

normalement, quand on a autant de donnée, on charge uniquement ce qui est nécessaire d'un coup. Un écran fait max 1500 pixels de haut. Une police lisible, 8pixels minimum. Ça te fait 187 lignes affichées d'un coup. Si tu affiche en, disons 10 colonnes, çà te fait grosso modo 2000 entrées à charger en mémoire. Si tu rajoute un cache 'une page avant, une page après' pour le défilement, çà nous amène à 6000 lignes en mémoire. Pas de quoi fouetter un chat. On est loin des 200.000 lignes à garder en mémoire Et puis, oublie pas que 200.000 données rapatriées, çà veux dire, à 1024 octets la lignes (suppositon raisonable) 200M de données qui circulent sur le réseau et transitent dans le driver JDBC, assez gourmand

[donnadieujulien]

Je suis d'accord avec toi mais j'ai vu qu'avec DB2 on peut pas faire un select entre telle et telle entrée, donc j'ai fait quelque chose comme :

FETCH 2000000 FIRST ROWS ONLY

Mias j'ai pas trouvé de commande pour sélectionner un intervalle qui ne commence pas au premier résultat...

[donnadieujulien]

J'affiche les données dans un JTbale + ScrollPane, donc je peux en mettre beacoup plus!!! et c'est toujours lisible...

[tchize_]

J'affiche les données dans un JTbale + ScrollPane, donc je peux en mettre beacoup plus!!! et c'est toujours lisible...

oui mais tout n'est pas à l'écran en meme temps et la JTable ne fait le rendu que de la partie visible!


Je ne connais pas DB2, mais les drivers JDBc, d'une manière générale, permettent d'explorer les résultat d'une requete au fur et à mesure grâce aux méthode next(), previous() et absolute(int row).

Code :

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

1
2
3
4
5
       Statement stmt = con.createStatement(
                                      ResultSet.TYPE_SCROLL_INSENSITIVE,
                                      ResultSet.CONCUR_READ_ONLY);
       ResultSet rs = stmt.executeQuery("SELECT a, b FROM TABLE2");
       rs.absolute(1500); //go to row 1500

[donnadieujulien]

Si je fais le bout de code que tu viens de noter, le resultset va se prendre tous les résultats quand même puisque la clause FETCH n'est pas directement dans la requete (selon moi).

Or le manque de mémoire vient plus du fait de cette requete qui va me ramener des milliers voire des millions d'items, que de l'affichage lui même, surtout si tu me dis que l'affichage de la JTable se fait au fur et a mesure (toujours selon moi).

Y'a l'instruction LIMIT X,Y, mais qui ne fonctionne pas apparement sous DB2....

[bredelet]

Il y a une solution pour DB2 pour récupérer N enregistrements d'un coup:

Code :

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

1
2
3
4
5
6
7
SELECT * FROM (
SELECT
ROW_NUMBER() OVER (ORDER BY key ASC) AS rownum,
columns
FROM tablename
) AS foo
WHERE rownum > skip AND rownum <= (n+skip)

Vois la doc de row_number pour les détails.

[tchize_]

a tester, même si db2 ne fournis pas de limitation au niveau sql, rien ne dit que le protocole en lui meme ne permet pas une transmission par bouts.

[donnadieujulien]

J'ai résolu mon problème en augmentant le heap size à 1Go

Merci

[CheryBen]

J'ai résolu mon problème en augmentant le heap size à 1Go

Merci

Cela fonctionne sur ton poste de développement, mais est-ce que les machines cibles chez ton client ont 1Go allouables à la JVM ? (pas sûr que ça existe ce mot)

[in]

Le nombre d'enregistrements que contient au maximum to resultSet est défini par le fetch size. (si je ne m'abuse par défaut c'est 10 ?)

Tu peux le définir avec

setFetchSize(int rows)
Gives the JDBC driver a hint as to the number of rows that should be fetched from the database when more rows are needed.

Ton problème de mémoire ne vient pas de la taille du résultat de la requête mais bien du nombre d'objets que tu instancies ...