Discussion :

[gloglo]

Salut

j'ai des données dans deux tables que je dois comparer. En fait pour chaque enregistrement de la première table, je dois voir s'il y a le meme dans la deuxième sauf que ici j'ai des tables de 4000 enregistrements. Lorsque j'ai testé mon pg avec des petites tables ça marche mais en testant avec les vrais tables qui sont super grosses tomcat me sort l'erreur suivante :

type Rapport d'exception

message

description Le serveur a rencontré une erreur interne () qui l'a empêché de satisfaire la requête.

exception

javax.servlet.ServletException: L'exécution de la servlet a lancé une exception
org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:362)


cause mère

java.lang.OutOfMemoryError: Java heap space


uelqu'un a peut etre une solution à mon probleme ?

Merci

[Mister Nono]

Et oui, le programmeur oublie souvent de tester les structures de données avec une quantité suffisante de données qui sera calculée en fonction de la prévision d'utilisation de l'application.

Mais quand le système s'écroule suite aux tests, il faut bien souvent revoir son algorithme pour optimiser les actions, processus, mémoire...

Bon tests.

[Mister Nono]

Il existe aussi la possibilité de modifier la quantité de mémoire qu'utilise la JVM : voir les options de la commande java : mais est-ce la meilleure solution ?

En tout cas, cela peut peut-être dépanner.

[gloglo]

Oui mais il n'y a pas un moyen de configurer Tomcat pour que son temsp d'attente soit mieux.

[gloglo]

Il existe aussi la possibilité de modifier la quantité de mémoire qu'utilise la JVM : voir les options de la commande java : mais est-ce la meilleure solution ?

En tout cas, cela peut peut-être dépanner.

Je pense que c la solution que je vais adopter. Mais comment faire pour modifier la quantité de mémoire de la JVM.

[killerock35]

Bonjour,

Il y a .exe qui s'appelle [%rep-tomcat%]/bin/tomcat5w.exe
Il est a utilisé si tomcat est un service.
Execute-le et vois l'onglet Java.
Regle les tailles des memory-pool.

A charge de revenche.....

[zekey]

Ola Ola stooopppp. Si avec 4000 rows ca foire c'est que le design ou l'algo est mauvais (pour 4 milliard je dis pas mais 4000). Avant d'augmenter la mémoire dans ce genre de cas il faut réfléchir à l'algo.

Pourrais tu décrire ton algo stp.

[wace]

Ton prob vients de la Heapsize de ta JVM
Modifie la valeur -XX:MaxPermSize au demarrage de ta jvm et tout ira bcp mieux,

[Mister Nono]

Ola Ola stooopppp. Si avec 4000 rows ca foire c'est que le design ou l'algo est mauvais (pour 4 milliard je dis pas mais 4000). Avant d'augmenter la mémoire dans ce genre de cas il faut réfléchir à l'algo.

Pourrais tu décrire ton algo stp.

Tout à fait d'accord : l'algo doit-être à revoir.

[derek.mf]

Salut,

Il me semble que tu devrais faire en sorte que ce soit le serveur de base de données qui effectue la plus grosse part du boulot :

si tu récupère toutes les lignes d'une table dans un resultset A puis toutes les lignes d'une autre dans un resultset B, puis qu'enfin tu compares les deux ça ne sera absolument pas performant sachant que tu peux faire la comparaison direct en SQL avec des algorithmes qui ont été optimisés à mort par des experts en la matière pour que leur SGBD soit performant.

Après, je ne sais pas vraiment pourquoi tu dois faire cela, peut être que ton application l'exige mais je suis quasiment sur que ce n'est pas l'algorithme qui est revoir mais plutôt ta stratégie pour obtenir ton résultat.

@+

derek.mf