[ExecutorService] transmettre les paramètres JVM [Résolu]

[tooms4444]

Bonjour à tous,

Pour pouvoir exécuter un traitement (Ghost4j), j'ai dû augmenter les capacités mémoire de la JVM ; ainsi j'ai pu exécuter mes tests :

-Xms64m
-Xmx512m
-XX:MaxPermSize=128m

Comme ces traitements sont répétitifs et prennent pas mal de temps par rapport au temps d'exécution de l'application, j'ai voulu passer la section concernée dans un thread :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
this.executor = Executors.newCachedThreadPool();
...
this.executor.execute(new Runnable() {
	public void run() {
		File thumbnail = generatePdfThumbnail(file); // Ghost4j
		if (thumbnail != null) {
			String thumbnailLink = buildLink(refDir, thumbnail);
			builder.buildThumbnailNode(node, thumbnail, thumbnailLink);
		}
	}
});
...
this.executor.shutdown();

Seulement, lorsque j'exécute le traitement, il s'avère que les paramètres mémoire ne sont manifestement pas transmis au thread :

Exception in thread "pool-1-thread-13" java.lang.OutOfMemoryError: Java heap space

Quelqu'un sait-il ce qu'il convient de faire, SVP ?
Merci d'avance.

[thelvin]

Envoyé par tooms4444

Seulement, lorsque j'exécute le traitement, il s'avère que les paramètres mémoire ne sont manifestement pas transmis au thread :

Bien sûr que si. Les threads font partie de l'application, ils utilisent la même mémoire.

Par contre, si tu fais ça dans une logique de threads avec Executors.newCachedThreadPool(), ce code va être exécuté pas plusieurs threads à la fois, et chacun d'eux va consommer de la mémoire.

Du coup, même si la mémoire suffit pour faire un traitement à la fois, elle ne suffit pas pour en faire plus d'un.
Il ne faut pas avoir plusieurs threads. Seulement un seul. Avec newSingleThreadExecutor().

[sinok]

Ou un fixedThreadPool, qui s'assure du nombre maximum de threads en parallèle.

[tooms4444]

Merci à tous les deux ; mais je ne voix pas l'intérêt du SingleThread ??
Quant au FixedThread, j'ai mis à 2 ; et ça plante encore...

[Heimdal]

mais je ne voix pas l'intérêt du SingleThread ??

A lancer une tache asynchrone par exemple.
Ou encore éviter que plus d'une tache qui parait anormalement gourmande ne tourne en parallèle.

Tu peux encore augmenter ton Xmx (au moins à 1024, après ça dépendra de ton runtime et de ton OS 32 ou 64 bits).
Etant donné que t'as mémoire gonflera à coup sur tu peux mettre ton Xms à la même valeur (ça ne changera rien au pb mais ca evite de perdre du temps à allouer plusieurs fois)
Tu peux sans doute gratter de la mémoire sur ton MaxPermSize.

Je ne connais pas Ghost4j mais je trouve particulièrement louche que tu aies besoin de 512M pour générer des pdfs.

Je suppose que la meilleure solution ne réside pas dans l'augmentation infinie de la mémoire allouée à la JVM.

[tooms4444]

éviter que plus d'une tache qui parait anormalement gourmande ne tourne en parallèle

Ouaich, on en est là...

En fait c'est un traitement qui crée des vignettes PNG à partir de fichiers PDF.
J'ai fait des essais avec PDF Renderer, PDF box et jPedal, mais seul GhostScript a traité l'ensemble des éléments affichés, qui plus est sur des formats multiples.
L'extraction de la première page (cover) prend 25 minutes, tandis que le traitement sans extraction PNG passe en 3s. Je précise toutefois qu'il y a environ 300 fichiers PDF (on n'a donc que quelques secondes d'extraction par fichier).

J'avais augmenté les paramètres JVM pour que ça fonctionne, mais je pensais (bêtement) passer entre les gouttes avec du threading. Je comprends maintenant que le ratio entre le temps "sans" et celui "avec" traitement GhostScript est beaucoup trop grand pour que ça donne quelque chose, eu égard au nombre de fichiers PDF.

Il me reste à faire des essais avec IcePdf ; quelqu'un a des infos là-dessus, SVP ?