Java JVM performances / garbage collector

Lionel wrote:

Bonjour,

J'ai une appli web struts/hibernate qui tourne sur websphere5/oracle sous
winXP.
Elle a des besoins en mémoire assez gros pour certaines requetes: elles
remontent plusieurs milliers d'objets, (posés sur la HttpServletRequest).
Si je fais un appel à Runtime.freeMomory() avant et après, j'ai un delta de
-80Mo en moyenne (est-ce fiable comme indication ?).
Entre le lancement de la requete oracle, et le moment ou tous les objets ont
été chargés dans ma
servlet il se passe 5 à 6 secondes. (Utilisant hibernate, je ne vois pas
trop comment isoler le temps
de la requete sql)
Lors de l'affichage du tableau par la jsp, j'ai systématiquement un appel au
garbage collector identique à celui ci:

<AF[4]: Allocation Failure. need 770608 bytes, 68096 ms since last AF>
<AF[4]: managing allocation failure, action=1 (78473408/533723648)
(3145728/3145728)>
<GC(4): GC cycle started Wed Feb 09 12:03:47 2005
<GC(4): freed 337237824 bytes, 78% free (418856960/536869376), in 335 ms>
<GC(4): mark: 308 ms, sweep: 27 ms, compact: 0 ms>
<GC(4): refs: soft 0 (age >= 32), weak 0, final 54, phantom 0>
<AF[4]: completed in 336 ms>

Je suis en monoprocesseurr avec une JVM IBM 1.3.1, avec les
paramètres -verbose:gc -Xms512m -Xmx512m.
Je ne vois pas d'autres paramètres pour cette VM.
Je connaissais pas l'option -verbose:gc, ca devrait pouvoir me servir

Lorsque mon appli est déployée sur le serveur (HP-UX 64bits biproc 750Mhz
RISC) les performances sont catastrophiques: tout est exactement 6 fois plus
lent que sur mon poste de dév pour la meme requete dans les meme conditions.
Le simple parcours de l'iterator est 2 fois plus lent sur le serveur
que sur mon poste (1.1 seconde contre 0.5sec)
Le truc classic pour faire chuter les perf, c'est le manque de mémoire

et le moment ou le systeme commence à swapper.
Plutot que le processeur, à ta place, je me rencarderais sur les dispo
en mémoire du serveur.

Je n'ai pas accès au serveur pour savoir si c'est le garbage collector qui
ralentit autant l'application en occupant le cpu.
Le serveur utilise une Java HotSpot(TM) Server VM 1.3.1.09.
Pourquoi ne pas utilisé la meme JVM en dev que sur le serveur ?

Et pourquoi ne pas installer une 1.5, elle est quand meme plus performante !

Comment expliquer un tel écart de perf alors que ce serveur est censé etre
nettement plus puissant sur le papier ?
Le GC et/ou la JVM peuvent elles etre responsables d'un tel écart ?

Note:
Ce serveur de test héberge une vingtaine d'applications, mais je n'ai aucune
possibilité de savoir ce qu'elle font ni qui les utilise en meme temps que
moi.
Je suppose que ce sont ces appli qui bouffent le cpu et ralentissent mon
appli, mais ne peux pas dépasser le stade de la supposition...
je cherche donc à optimiser mon appli et son paramétrage au mieux avant de
remettre en cause le serveur.
Il serait quand meme souhaitable que tu accède à cette machine pour

savoir ce qui passe...

Ne serai-ce que pour pouvoir suivre la consomation mémoire/proc pendant
l'execution de ta requete.

Actuellement, je ne vois pas comment faire mieux sur mon poste de dév.
C'est le momment de faire copain-copain avec les gens de la prod pour

voir ce qui ce passe sur ce serveur.

Merci pour vos conseils et expériences similaires...
Mon retoure d'expérience, c'est que quand un prog Java commence à swapé,

c'est souvent le début de la fin.

@+

Black Myst wrote:

Le truc classic pour faire chuter les perf, c'est le manque de mémoire
et le moment ou le systeme commence à swapper.
Plutot que le processeur, à ta place, je me rencarderais sur les dispo
en mémoire du serveur.

Je pense également que le pb vient de là
10Go de ram sur le serveur.
256Mo en recette pour mon appli, 512Mo en prod.
Je ne connais pas le paramétrage des autres applis.

Pourquoi ne pas utilisé la meme JVM en dev que sur le serveur ?
Je n'ai pas de système 64bits chez moi :-)

Et pourquoi ne pas installer une 1.5, elle est quand meme plus
performante !
hum. Tu connais un websphere en VM 1.5 ?

En prod j'ai un WAS 5.0.2 en VM 1.3.
WAS 5.1 utilise une VM 1.4. Y a plus qu'à attendre la migration :)

Il serait quand meme souhaitable que tu accède à cette machine pour
savoir ce qui passe...
Ne rêvons pas :)

Ne serai-ce que pour pouvoir suivre la consomation mémoire/proc
pendant l'execution de ta requete.
Il y a 3 admin websphere pour ce serveur, c'est leur job, non ?

C'est le momment de faire copain-copain avec les gens de la prod pour
voir ce qui ce passe sur ce serveur.
Ils sont probablement protégés par 18 gardes du corps, enfermés dans une

cave, 200m sous terre. :)
Je ne peux meme pas leur téléphoner.

Mon retoure d'expérience, c'est que quand un prog Java commence à
swapé, c'est souvent le début de la fin.
C'est ce que je pense aussi.

"Lionel" <SPAMcoollATfreePOINTfr> wrote in message news:<420a019e$0$9480$626a14ce@news.free.fr>...

Bonjour,

J'ai une appli web struts/hibernate qui tourne sur websphere5/oracle sous
winXP.
Elle a des besoins en mémoire assez gros pour certaines requetes: elles
remontent plusieurs milliers d'objets, (posés sur la HttpServletRequest).
Si je fais un appel à Runtime.freeMomory() avant et après, j'ai un delta de
-80Mo en moyenne (est-ce fiable comme indication ?).
Entre le lancement de la requete oracle, et le moment ou tous les objets ont
été chargés dans ma
servlet il se passe 5 à 6 secondes. (Utilisant hibernate, je ne vois pas
trop comment isoler le temps
de la requete sql)

A mon avis tu as intérêt à mettre en place un workaround pour ces
requêtes spécifiques. 5-6s c'est énorme et cela plombe sans doute
complètement l'appli pour d'autres opérations. Tu as peu de chance de
monter en charge avec des requêtes problématiques comme ça. Utilise
des proc stock ou des requêtes plus générales pour traiter ces pb
particuliers.

Gaetan Zoritchak wrote:

A mon avis tu as intérêt à mettre en place un workaround pour ces
requêtes spécifiques. 5-6s c'est énorme et cela plombe sans doute
complètement l'appli pour d'autres opérations. Tu as peu de chance de
monter en charge avec des requêtes problématiques comme ça. Utilise
des proc stock ou des requêtes plus générales pour traiter ces pb
particuliers.

il s'agit d'un select tout simple: le résultat d'un moteur de recherche dans
aucun filtre.
Ce n'est pas vraiment la requete sql qui pose problème (sinon cela serait
facile à résoudre), c'est la quantité d'informations qui sont remontées.
La collection remontée occupe 80Mo de mémoire.
Je milite pour que seuls une poignée d'utilisateurs aient accès au moteur de
recherche sans aucun filtre obligatoire, mais c'est pas gagné.
Actuellement une trentaine sur 110 y ont accès.
Et encore je peux faire pire, j'ai une table dans laquelle 500000 lignes
sont ajoutées chaque mois, avec laquelle une jointure peut être nécessaire
(selon les filtres sélectionnés).

Bonjour,

J'ai une appli web struts/hibernate qui tourne sur websphere5/oracle sous
winXP.
Elle a des besoins en mémoire assez gros pour certaines requetes: elles
remontent plusieurs milliers d'objets, (posés sur la HttpServletRequest).

Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est sûrement
là que sont tes 80 Mo.

Si je fais un appel à Runtime.freeMomory() avant et après, j'ai un delta de
-80Mo en moyenne (est-ce fiable comme indication ?).
Entre le lancement de la requete oracle, et le moment ou tous les objets ont
été chargés dans ma
servlet il se passe 5 à 6 secondes. (Utilisant hibernate, je ne vois pas
trop comment isoler le temps
de la requete sql)
Lors de l'affichage du tableau par la jsp, j'ai systématiquement un appel au
garbage collector identique à celui ci:

<AF[4]: Allocation Failure. need 770608 bytes, 68096 ms since last AF>
<AF[4]: managing allocation failure, action=1 (78473408/533723648)
(3145728/3145728)>
<GC(4): GC cycle started Wed Feb 09 12:03:47 2005
<GC(4): freed 337237824 bytes, 78% free (418856960/536869376), in 335 ms>
<GC(4): mark: 308 ms, sweep: 27 ms, compact: 0 ms>
<GC(4): refs: soft 0 (age >= 32), weak 0, final 54, phantom 0>
<AF[4]: completed in 336 ms>

Je suis en monoprocesseurr avec une JVM IBM 1.3.1, avec les
paramètres -verbose:gc -Xms512m -Xmx512m.
Je ne vois pas d'autres paramètres pour cette VM.

Lorsque mon appli est déployée sur le serveur (HP-UX 64bits biproc 750Mhz
RISC) les performances sont catastrophiques: tout est exactement 6 fois plus
lent que sur mon poste de dév pour la meme requete dans les meme conditions.
Le simple parcours de l'iterator est 2 fois plus lent sur le serveur
que sur mon poste (1.1 seconde contre 0.5sec)
Je n'ai pas accès au serveur pour savoir si c'est le garbage collector qui
ralentit autant l'application en occupant le cpu.
Le serveur utilise une Java HotSpot(TM) Server VM 1.3.1.09.

Comment expliquer un tel écart de perf alors que ce serveur est censé etre
nettement plus puissant sur le papier ?

Parce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.
Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas ce
que c'est ton hpux risc) torche un PC parce qu'il est testé avec une
application consommatrice d'I/O (ce en quoi le PC est mauvais et un
serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
Pour faire un traitement con en mémoire avec un seul thread (par exemple
parcourir un énorme itérateur avec beaucoup trop d'objets) un CPU intel
torche n'importe quel cpu 64 bits riscs avec turbo-compresseur à
induction nucléaire.
A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme
poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz (mais bon, ne sachant si c'est un itanium ou un
pa, et n'en ayant un sous la main pour foutre un coup de chronomètre
dessus, c'est assez imprécis comme estimation).
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP. D'ailleurs pour jouer à
Half-Life 2 rien ne vaut un PC.

Le GC et/ou la JVM peuvent elles etre responsables d'un tel écart ?

La JVM peut y être un peu pour quelque chose aussi, et même l'OS si le
niveau de patch est débile par rapport aux patches JVM. Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le sature.
Mais de loin le plus probable c'est ce que je dis ci-dessus.

Note:
Ce serveur de test héberge une vingtaine d'applications, mais je n'ai aucune
possibilité de savoir ce qu'elle font ni qui les utilise en meme temps que
moi.
Je suppose que ce sont ces appli qui bouffent le cpu et ralentissent mon
appli, mais ne peux pas dépasser le stade de la supposition...
je cherche donc à optimiser mon appli et son paramétrage au mieux avant de
remettre en cause le serveur.

C'est une très bonne démarche.

Actuellement, je ne vois pas comment faire mieux sur mon poste de dév.

Merci pour vos conseils et expériences similaires...

a+

Derek Sagan wrote:

Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.
Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.

Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un seul
coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate

Parce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.
Très probable.

Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas
ce que c'est ton hpux risc)
moi non plus

torche un PC parce qu'il est testé avec
une application consommatrice d'I/O (ce en quoi le PC est mauvais et
un serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
un CPU intel torche n'importe quel cpu 64 bits riscs avec
turbo-compresseur à induction nucléaire.
Bien vu.

A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme
PIV 3GHz.

poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP.
Pas ma boite. Mon client.

Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et 10 fois
plus performant.

Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le
sature.
Va savoir, il y a plus de 20 autres applis sur ce serveur.

Mais de loin le plus probable c'est ce que je dis ci-dessus.
Tu m'as convaincu

Merci.

"Lionel" <cooll AT free POINT fr> wrote:

Derek Sagan wrote:

Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.
Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.

Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un seul
coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate

Mouarf, et ils exploitent les 6000 lignes bien sur :)

C'est du délire, il faut affiner les critères et éduquer les utilisateurs
pour leur faire comprendre que ce qu'ils demandent est inutilisable
d'une part, et en plus ca effondre l'applie d'autre part (enfin d'après
ce que tu dis).

--
Cordialement,

Patrice Trognon
http://wwW.javadevel.com

"Lionel" <SPAMcoollATfreePOINTfr> wrote:

Black Myst wrote:

Le truc classic pour faire chuter les perf, c'est le manque de mémoire
et le moment ou le systeme commence à swapper.
Plutot que le processeur, à ta place, je me rencarderais sur les dispo
en mémoire du serveur.

Je pense également que le pb vient de là
10Go de ram sur le serveur.
256Mo en recette pour mon appli, 512Mo en prod.
Je ne connais pas le paramétrage des autres applis.

Pourquoi ne pas utilisé la meme JVM en dev que sur le serveur ?
Je n'ai pas de système 64bits chez moi :-)

Et pourquoi ne pas installer une 1.5, elle est quand meme plus
performante !
hum. Tu connais un websphere en VM 1.5 ?

En prod j'ai un WAS 5.0.2 en VM 1.3.
WAS 5.1 utilise une VM 1.4. Y a plus qu'à attendre la migration :)

[...]

De mémoire, HP-UX n'est pas forcement la meilleur archi pour
faire tourner du Java.

<mode_troll>
Je ne vois qu'une solution pour faire tourner toute ton
usine (WebSphere, hibernate, etc etc) c'est d'installer
un E10K ou E15K.
En faisant ce qu'il faut pour avoir assez de mémoire
et assez de noeuds CPU, a mon avis tu devrais retrouver
des perfs correctes.

Ou encore monter un cluster de 8 Bi Xeon ....

J'arrete la ca ira ;)
</mode_troll>

en bref, bonne chance :)


--
Cordialement,

Patrice Trognon
http://wwW.javadevel.com

Derek Sagan wrote:

Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.

Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.
Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un seul
coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate

Alors le choix d'hibernate n'est pas adapté à ton problème.
Mauvais outil changer d'outil.
Plus encore mauvaise méthode changer de méthode.

J'espère que tu ne veux pas dire qu'à chaque fois que l'utilisateur
charge une page de 30 lignes hibernate charge 6000 lignes. Ni que tu
garde les 6000 lignes une fois pour toute dans un objet persistant d'une
requête à l'autre, genre ta session voire (pire) un singleton à toi qui
sera purger quand les poules auront des dents.
Faire ça sur un serveur mutualisé ca devrait être passible de la cour
martiale. ;-)

Si tu avais la main sur la requête tu peux ne charger que 30 lignes à la
fois mais je ne suis pas sûr qu'Hibernate sache faire...

Parce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.

Très probable.

Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas
ce que c'est ton hpux risc)

moi non plus

torche un PC parce qu'il est testé avec
une application consommatrice d'I/O (ce en quoi le PC est mauvais et
un serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
un CPU intel torche n'importe quel cpu 64 bits riscs avec
turbo-compresseur à induction nucléaire.

Bien vu.

A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme

PIV 3GHz.

poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP.

Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et 10 fois
plus performant.

Ce qui n'aurai pas résolu tes problèmes de performance qui n'ont rien
avoir avec le hard mais avec ton soft (celui que tu fais et celui que tu
intègre (hibernate)).

Sans vouloir paraître dur avec toi, si tu ne sais pas que ton unix est
moins performant que ton poste de travail sur un traitement monothreadé,
je pense qu'il y a beaucoup de pièges pires dans lequel tu tomberais
avec un cluster, surtout si tu veux dire par là un ensemble de machines
toutes actives en même temps (et pas une paire dont l'une des deux
attend que l'autre tombe). Ton client a donc eu raison de ne pas
t'infliger un cluster ;-)

Au fait si ce n'est pas la puissance CPU pure qui vaut le coup de payer
un unix cher, c'est peut-être autre chose... Je ne connais pas ton
client, mais un serveur unix ça a du hard redondant, ça sait faire du
scale-up (pour une base de données par exemple dans beaucoup de cas (pas
tous) les cluster et les trucs distribués c'est du pipo marketing ça ne
marche pas ou bcp moins bien)), c'est intégré correctement dans les
process et avec les produits faits pour faire de la haute-dispo et du
plan de secours (SAN, etc.).
Tout ça on peut le refaire avec des Linux boxes et le savoir-faire
idoine, mais ça va coûter *beaucoup* plus cher que le seul prix des
machines. Et les compétences pour faire ça sont rares. Parce que le
savoir-faire en question est presque uniquement chez les constructeurs
d'unix propriétaires et qu'ils n'ont pas envie de le brader.

Mais peut-être que je me trompe. Que ton client n'a pas de besoin de
haute dispo, ni de plan de secours en cas d'incendie/dégâts des
eaux/chute d'avion. Peut-être juste que le commercial d'HP a les dents
blanches, auquel cas je comprends ta réaction.
Sur l'île de la Réunion, il y a en tout quelque chose comme 20 km
d'autoroute, et il y a des gens qui ont des Porsches et des grosses BMW.
Peut-être que ton client a payé un truc dont il ne se sert pas juste
parce qu'il croit qu'une machine qui coûte 10 fois le prix de son
portable tourne 10 fois plus vite... (foutus commerciaux)

a+

Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le
sature.

Va savoir, il y a plus de 20 autres applis sur ce serveur.

Mais de loin le plus probable c'est ce que je dis ci-dessus.

Tu m'as convaincu


Merci.

Derek Sagan wrote:

Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.

Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.
Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un seul
coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate

Alors le choix d'hibernate n'est pas adapté à ton problème.
Mauvais outil changer d'outil.
Plus encore mauvaise méthode changer de méthode.

J'espère que tu ne veux pas dire qu'à chaque fois que l'utilisateur
charge une page de 30 lignes hibernate charge 6000 lignes. Ni que tu
garde les 6000 lignes une fois pour toute dans un objet persistant d'une
requête à l'autre, genre ta session voire (pire) un singleton à toi qui
sera purger quand les poules auront des dents.
Faire ça sur un serveur mutualisé ca devrait être passible de la cour
martiale. ;-)

Si tu avais la main sur la requête tu peux ne charger que 30 lignes à la
fois mais je ne suis pas sûr qu'Hibernate sache faire...

Parce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.

Très probable.

Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas
ce que c'est ton hpux risc)

moi non plus

torche un PC parce qu'il est testé avec
une application consommatrice d'I/O (ce en quoi le PC est mauvais et
un serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
un CPU intel torche n'importe quel cpu 64 bits riscs avec
turbo-compresseur à induction nucléaire.

Bien vu.

A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme

PIV 3GHz.

poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP.

Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et 10 fois
plus performant.

Ce qui n'aurai pas résolu tes problèmes de performance qui n'ont rien
avoir avec le hard mais avec ton soft (celui que tu fais et celui que tu
intègre (hibernate)).

Sans vouloir paraître dur avec toi, si tu ne sais pas que ton unix est
moins performant que ton poste de travail sur un traitement monothreadé,
je pense qu'il y a beaucoup de pièges pires dans lequel tu tomberais
avec un cluster, surtout si tu veux dire par là un ensemble de machines
toutes actives en même temps (et pas une paire dont l'une des deux
attend que l'autre tombe). Ton client a donc eu raison de ne pas
t'infliger un cluster ;-)

Au fait si ce n'est pas la puissance CPU pure qui vaut le coup de payer
un unix cher, c'est peut-être autre chose... Je ne connais pas ton
client, mais un serveur unix ça a du hard redondant, ça sait faire du
scale-up (pour une base de données par exemple dans beaucoup de cas (pas
tous) les cluster et les trucs distribués c'est du pipo marketing ça ne
marche pas ou bcp moins bien)), c'est intégré correctement dans les
process et avec les produits faits pour faire de la haute-dispo et du
plan de secours (SAN, etc.).
Tout ça on peut le refaire avec des Linux boxes et le savoir-faire
idoine, mais ça va coûter *beaucoup* plus cher que le seul prix des
machines. Et les compétences pour faire ça sont rares. Parce que le
savoir-faire en question est presque uniquement chez les constructeurs
d'unix propriétaires et qu'ils n'ont pas envie de le brader.

Mais peut-être que je me trompe. Que ton client n'a pas de besoin de
haute dispo, ni de plan de secours en cas d'incendie/dégâts des
eaux/chute d'avion. Peut-être juste que le commercial d'HP a les dents
blanches, auquel cas je comprends ta réaction.
Sur l'île de la Réunion, il y a en tout quelque chose comme 20 km
d'autoroute, et il y a des gens qui ont des Porsches et des grosses BMW.
Peut-être que ton client a payé un truc dont il ne se sert pas juste
parce qu'il croit qu'une machine qui coûte 10 fois le prix de son
portable tourne 10 fois plus vite... (foutus commerciaux)

a+

Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le
sature.

Va savoir, il y a plus de 20 autres applis sur ce serveur.

Mais de loin le plus probable c'est ce que je dis ci-dessus.

Tu m'as convaincu


Merci.