Problème de taille mémoire

Version imprimable

Bonjour

J'ai une servlet de sauvegarde de bdd qui génère et retourne un fichier texte sql zippé. la taille du fichier fait environ 25Mo de données (8.2 Mo zippé)
Les données sont stokées dans une StringBuffer avant compression.
La mémoire allouée au système est celle du package d'installation sans modif.
Depuis peu, j'ai cette erreur qui remonte et je ne peux plus faire de sauvegarde:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 5 déc. 2013 10:01:10 org.apache.catalina.core.StandardWrapperValve invoke GRAVE: "Servlet.service()" pour la servlet gest_mat a généré une exception java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390) at java.lang.StringBuffer.append(StringBuffer.java:224) at administration.SauvegardeBdd.sauvegardeSql(SauvegardeBdd.java:67) at administration.SauvegardeBdd.sauvegardeBdd(SauvegardeBdd.java:41) at administration.IndexAdministration.main(IndexAdministration.java:115) at index.GestMat.doGet(GestMat.java:395) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
Config: Java 7 / Tomcat 7 / Mysql 5.5

Pouvez vous m'aiguiller
Merci

05/12/2013, 17h59
thelvin

Citation:

Envoyé par Mengué georges

Les données sont stokées dans une StringBuffer avant compression.

Ne pas faire ça me semble la piste la plus évidente.

Stocker dans un fichier, ou envoyer dans la socket, ou quoi que ce soit d'autre que garder un fichier de plusieurs mégas en mémoire juste pour le compresser...
05/12/2013, 18h11
Mengué georges

La solution ce serait quoi shématiquement ?

Bonjour,

Utilise un BufferedOutputStream* :

Code:

OutputStream bufferedOutputStream = new BufferedOutputStream(new GZIPOutputStream(new FileOutputStream("monFichier.tar.gz")));

pour écrire tes données dans un fichier plutôt que de tout stocker en mémoire et écrire d'un coup l'ensemble.

A chaque fois que tu appelles la méthode bufferedOutputStream.write() Java stock tes données en mémoire jusqu'à atteindre la taille limite du buffer. Quand la taille limite du buffer est atteinte, Java écrit ce qu'il a en mémoire dans le flux et vide le buffer. Et ainsi de suite...

* Si tu veux écrire des String plutôt que des byte[] tu peux utiliser BufferedWriter à la place :
Code:

1 2 3 Writer bufferedOutputWriter = new BufferedWriter(new OutputStreamWriter(new GZIPOutputStream(new FileOutputStream("monFichier.tar.gz")))); bufferedOutputWriter.write("toto"); bufferedOutputWriter.close();
Romain.

05/12/2013, 18h33
Mengué georges

Donc si je suis ton rasonnement:
je stoke à la volé mes données sql dans un fichier au fil du traitement puis je zip ce fichier que je renvoie

Erreur, je rectifie:
A chaque élément à sauvegarder (table), j'appelle la méthode bufferedOutputStream.
Ce que j'ai du mal à appréhender c'est le cheminement (je suis un autodidacte à la retraite) qui pour vous qui êtes de la partie est une évidence.
05/12/2013, 18h46
thelvin

En fait, il serait encore plus simple de zipper ce fichier à la volée et de renvoyer à la volée le résultat zippé.

Et si ce que tu demandes, c'est comment faire ça, nous n'allons évidemment pas deviner qu'est-ce que tu appelles "renvoyer." C'est quoi ton protocole, c'est quoi tes interfaces.
05/12/2013, 19h05
Mengué georges

Mon appli est web du type MCV2 qui est déployée localement via un pack qui comprend la jvm, tomcat et mysql, les réseaux et serveurs étant verrouillés par la direction informatique.
J'ai installé un démonstrateur dans le Cloud d'AppFoghttp://sigmaint.eu01.aws.af.cm/gest_matlog jojo; pass bill
05/12/2013, 19h43
rg77140

Avec le code que je t'ai donné tu écris directement un flux "gzippé" (grâce au new GZIPOutputStream()). Dans mon exemple j'ai écris dans un fichier (grâce au new FileOutputStream()) mais tu pourrais écrire dans un flux ouvert avec le client... A la place du FileOutputStream passe le stream que tu avais avant.

Romain.

Et bien, je dirais qu'une solution serait un truc du genre

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
try (ZipOutputStream zos = new ZipOutputstream(response.getOutputStream())){
  zos.putNextEntry(new ZipEntry("datas.sql"));
  try(PrintWriter pw = new PrintWriter(new OutputStreamWriter(zos,"UTF-8"))) {
    generateSql(bw);
  }
}
 
....
 
private void generateSql(PrintWriter writer){
   //....
   writer.println("insertor into machin des trucs");
   writer.println("insertor into machin des autres trucs");
   //...
}

06/12/2013, 07h12
Mengué georges

Bonjour à tous

Je souhaiterai rester compatible à java 6
06/12/2013, 09h05
adiGuba

Salut,

Citation:

Envoyé par Mengué georges

Je souhaiterai rester compatible à java 6

Et donc ? Quel est le problème ?

a++
06/12/2013, 09h20
joel.drigo

Salut,

Citation:

Envoyé par adiGuba

Et donc ? Quel est le problème ?

Juste le try-with-resources utilisé dans l'exemple de @Tchize_.

Citation:

Envoyé par Mengué georges

Je souhaiterai rester compatible à java 6

Ce lien explique très bien la correspondance entre le try-with-resource et l'écriture "à l'ancienne", avec try/finally.
06/12/2013, 09h59
Mengué georges

juste qu'eclipse génère une erreur et m'impose la compilation en java7

->Set project compiler compliance settings to 1.7

Version java 6, pas dure à adapter pourtant

Code:

1
2
3
4
5
6
7
8
9
10
11
12
ZipOutputStream zos = new ZipOutputstream(response.getOutputStream());
try{
  zos.putNextEntry(new ZipEntry("datas.sql"));
  PrintWriter pw = new PrintWriter(new OutputStreamWriter(zos,"UTF-8"))
  try {
    generateSql(pw);
  } finally {
    pw.close();
  }
} finally {
zos.close();
}

06/12/2013, 11h56
Mengué georges

Bien merci pour l'exemple
Après test il semble que l'espace mémoire utilisé soit inférieur. Il me faut aller chez les utilisateurs pour voir ce qu'il en est.