Application très lente sous solaris

**pchoucine** · 29/09/2009, 17h47

Bonjour,

j'ai un programme java qui fait des traitement sur les fichier texte

le lancement de cette programme sous win xp fait 6heur de traitement

mais sous solaris10 il fait plus que 10 jours je sais pas pourquoi merci de me aider.

**sovo** · 29/09/2009, 20h15

pour moi 6h c'est déjà énorme c'est quel genre de traitement ?

**pchoucine** · 30/09/2009, 14h07

Envoyé par sovo

pour moi 6h c'est déjà énorme c'est quel genre de traitement ?

==========
Bonjour
c'est un programme fait des traitement sur les fichiers plat 550Mo il regroupe des données et génére des fichiers de sortie

**tchize_** · 30/09/2009, 14h44

Il faudrait revoir ton algorithme. A mon avis il est trop lent. Sur la machine en question, est-ce le CPU qui est à 100% ou le travail du disque dur?

**pchoucine** · 30/09/2009, 15h04

Envoyé par tchize_

Il faudrait revoir ton algorithme. A mon avis il est trop lent. Sur la machine en question, est-ce le CPU qui est à 100% ou le travail du disque dur?

============
Bonjour

l'espace est suffisant il y a 2 prosse 480 pour la ram 2Go

**tchize_** · 30/09/2009, 15h09

c'est pas la question que je t'ai posée. Est-ce le disque dur ton bottleneck ou le CPU? Tu peux le voir facilement. Si pendant 6 heure t'as un CPU à 100%, c'est que ton algo suce le CPU. Si pendant les 6h ton CPU est à 10% mais que ton disque dur gratte comme un malade, c'est que ton algo suce les IOs.

**pchoucine** · 30/09/2009, 15h31

Envoyé par tchize_

c'est pas la question que je t'ai posée. Est-ce le disque dur ton bottleneck ou le CPU? Tu peux le voir facilement. Si pendant 6 heure t'as un CPU à 100%, c'est que ton algo suce le CPU. Si pendant les 6h ton CPU est à 10% mais que ton disque dur gratte comme un malade, c'est que ton algo suce les IOs.

==============
Bonjour

sur mon machine (win xp) qui fait 6heurs le cpu est presque 20%

**tchize_** · 30/09/2009, 15h38

dans ce cas, il faut revoir ton code, tu lit probablement beaucoup trop de fois les même données sur ton disque dur. Si on prend un fichier de 512M, il doit pouvoir etre lu en moins de 5 minutes par la pluspart des machine moderne. Si tu passe 6 heure à lire dessus, ca sous entendrais que tu passe presque 80 fois sur chaque zone du fichier.

Evidement, c'est qu'un supposition, on a pas la moidre idée d'a quoi ressemblent tes algorithmes!

**pchoucine** · 30/09/2009, 15h51

Envoyé par tchize_

dans ce cas, il faut revoir ton code, tu lit probablement beaucoup trop de fois les même données sur ton disque dur. Si on prend un fichier de 512M, il doit pouvoir etre lu en moins de 5 minutes par la pluspart des machine moderne. Si tu passe 6 heure à lire dessus, ca sous entendrais que tu passe presque 80 fois sur chaque zone du fichier.

Evidement, c'est qu'un supposition, on a pas la moidre idée d'a quoi ressemblent tes algorithmes!

==========
Bonjour
merci pour votre colaboration. non j'ai 482 fichier de somme de 550Mo je voire que 6heurs pas grave mais pour les méme fichiers et meme programme il fait plus que 10 jours sur une autre machine (serveur) avec une autre systeme solaris

**tchize_** · 30/09/2009, 16h06

Envoyé par pchoucine

6heurs pas grave mais pour les méme fichiers et meme programme il fait plus que 10 jours sur une autre machine (serveur) avec une autre systeme solaris

6h sur une bécane trés puissante dédiée uniquement à ce calcul, c'est énorme. Vu que l'autre machine doit probablement partager son CPU avec d'autres process, qu'elle n'a peut etre pas des IOs aussi performants et qu'elle a peut etre moins de CPU ou des CPUs moins rapide, rien d'étonnant qu'on passe à 10 jours. Encore une fois, sans code, difficile de te pointer tes erreurs.

**adiGuba** · 30/09/2009, 16h49

Salut,

+1 avec tchize_ : difficile de t'aider avec si peu d'info !

Mais à tout hasard : tu n'utiliserais pas des appels à System.gc() ???

a++

**pchoucine** · 30/09/2009, 17h20

Envoyé par adiGuba

Salut,

+1 avec tchize_ : difficile de t'aider avec si peu d'info !

Mais à tout hasard : tu n'utiliserais pas des appels à System.gc() ???

a++

voici ci-joint le code source de mon projet et aussi un exemple de fichier qui traite

**adiGuba** · 30/09/2009, 17h30

Comment déjà par libérer proprement tes fichiers via des try/finally...

a++

**tchize_** · 30/09/2009, 18h01

+1

De plus, ton ecrire(fileOut, s); un peu partout dans le code est une catastrophe. A chaque fois que tu veux écrire un petit bout de texte, tu réouvre le fichier, tu te position à la fin, t'écrit quelques octet et tu le referme. Ouvrir un fichier est une opération consommatrice de temps.

remplace

Code :

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

1
2
3
					String fileOut = pr.getProperty("output") + "/"
 
							+ fl[j].getName();

par

Code :

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

1
2
3
4
5
6
 
				PrintWriter fileOut = new PrintWriter(new BufferedWriter(
 
					new FileWriter(pr.getProperty("output") + "/"
 
							+ fl[j].getName(), true)));

ainsi que tous tes appels à

Code :

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

								ecrire(fileOut, s);

par

Code :

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

								fileOut.println(s);

Franchement, ton code lit linéairement 500M de données pour réécrire à peu près autant de données dans le fichier de sortie. Les traitement qu'il effectue sur chaque ligne, d'un point de vue mathématique, doivent consommer 1 à 2 milliseconde. Une telle opération sur un gros fichier ne devrais pas mettre plus de 10 minutes sur une bécane moyenne. Je comprend pas pourquoi, pour une opération aussi linéaire, tu trouve admissible de travailler 6h!

**pchoucine** · 30/09/2009, 18h25

Envoyé par tchize_

+1

De plus, ton ecrire(fileOut, s); un peu partout dans le code est une catastrophe. A chaque fois que tu veux écrire un petit bout de texte, tu réouvre le fichier, tu te position à la fin, t'écrit quelques octet et tu le referme. Ouvrir un fichier est une opération consommatrice de temps.

remplace

Code :

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

1
2
3
					String fileOut = pr.getProperty("output") + "/"
 
							+ fl[j].getName();

par

Code :

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

1
2
3
4
5
6
 
				PrintWriter fileOut = new PrintWriter(new BufferedWriter(
 
					new FileWriter(pr.getProperty("output") + "/"
 
							+ fl[j].getName(), true)));

ainsi que tous tes appels à

Code :

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

								ecrire(fileOut, s);

par

Code :

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

								fileOut.println(s);

Franchement, ton code lit linéairement 500M de données pour réécrire à peu près autant de données dans le fichier de sortie. Les traitement qu'il effectue sur chaque ligne, d'un point de vue mathématique, doivent consommer 1 à 2 milliseconde. Une telle opération sur un gros fichier ne devrais pas mettre plus de 10 minutes sur une bécane moyenne. Je comprend pas pourquoi, pour une opération aussi linéaire, tu trouve admissible de travailler 6h!

Merci pour votre aide je teste avec votre remarque je vous informe que c'est fichier se sont des facture de telephone et internet pour un operateur telecome.

**pchoucine** · 01/10/2009, 13h12

bonjour je vous informe que je change mon code, le temps d'execution est passe à 5h30 à la place de 6heurs mais je pence que sur solaris il dépace 10jours. je voire que le souci n'est pas sousci de code

**tchize_** · 01/10/2009, 15h08

on peux voir le code modifié?

**pchoucine** · 01/10/2009, 16h19

Envoyé par tchize_

on peux voir le code modifié?

bien sur

**tchize_** · 01/10/2009, 16h50

pour avoir une idée

quel est le nombre de fichiers d'input?
Quelle est la taille de listClientInt ?

peux tu donner un ensemble de fichiers de tests qu'on essaye?

Application très lente sous solaris

avec Java

Discussions similaires

Partager

Partager