au secours !

Général
1

Bonjour,
J'ai réinstallé la base et une heure plus tard le tueur de base d'ovh a frappé à nouveau !
Je vais simplifier mes requêtes...
Je vais aussi supprimer le cache comme m'a demandé une fois ovh.
L'adresse du site (quand j'aurais réinstaller une nouvelle base), c'est http://www.bibliosurf.com
Qui sait lire les données fournies par ovh ?
Merci de votre aide.
J'en ai bien besoin.
BS

+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| 109299 | mauvaisgapi | 10.0.63.45:58053 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109524 | mauvaisgapi | 10.0.63.47:54005 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109555 | mauvaisgapi | 10.0.63.37:35835 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109646 | mauvaisgapi | 10.0.63.42:41258 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109733 | mauvaisgapi | 10.0.63.42:41306 | mauvaisgapi | Sleep | 0 | | |
| 109738 | mauvaisgapi | 10.0.63.66:36088 | mauvaisgapi | Query | 0 | statistics | SELECT articles.id_article, articles.titre, articles.descriptif, articles.lang
FROM `mauvaisgapi`.sp |
| 109746 | mauvaisgapi | 10.0.63.63:56636 | mauvaisgapi | Query | 0 | removing tmp table | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |

2

Bernard Strainchamps a écrit :

Bonjour,
J'ai réinstallé la base et une heure plus tard le tueur de base d'ovh a frappé à nouveau !
Je vais simplifier mes requêtes...
Je vais aussi supprimer le cache comme m'a demandé une fois ovh.

si tu supprimes le cache, tu va pilonner la base de donnée ce qui ne me semble pas l'objectif souhaité

3

dixit ovh - et on retrouve des infos sur le web à ce sujet - le cache de spip pose problème sur les sites très fréquentés !!!

Julien Favre a écrit :

Bernard Strainchamps a écrit :
  

Bonjour,
J'ai réinstallé la base et une heure plus tard le tueur de base d'ovh a frappé à nouveau !
Je vais simplifier mes requêtes...
Je vais aussi supprimer le cache comme m'a demandé une fois ovh.
    
si tu supprimes le cache, tu va pilonner la base de donnée ce qui ne me semble pas l'objectif souhaité

_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : FAQ webmestre - SPIP

4

pourtant… le site de l’APEM… à 6000 visites par jour… il a pas de problème…

ed

Le 11/12/07, Rue des boulets < rue@ruedesboulets.com> a écrit :

dixit ovh - et on retrouve des infos sur le web à ce sujet - le cache de
spip pose problème sur les sites très fréquentés !!!

Julien Favre a écrit :

Bernard Strainchamps a écrit :

Bonjour,
J’ai réinstallé la base et une heure plus tard le tueur de base d’ovh a
frappé à nouveau !
Je vais simplifier mes requêtes…
Je vais aussi supprimer le cache comme m’a demandé une fois ovh.

si tu supprimes le cache, tu va pilonner la base de donnée ce qui ne me
semble pas l’objectif souhaité

liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip.net/fr_article1054.html

liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip.net/fr_article1054.html

–
Edouard Reinach
ereinach@gmail.com
+1 514 582 5156

War is God’s way of teaching Americans geography - Ambrose Bierce

5

transfère la question sur la liste dev

c'est quelle version de spip?

Bernard Strainchamps a écrit :

Bonjour,
J'ai réinstallé la base et une heure plus tard le tueur de base d'ovh a frappé à nouveau !
Je vais simplifier mes requêtes...
Je vais aussi supprimer le cache comme m'a demandé une fois ovh.
L'adresse du site (quand j'aurais réinstaller une nouvelle base), c'est http://www.bibliosurf.com
Qui sait lire les données fournies par ovh ?
Merci de votre aide.
J'en ai bien besoin.
BS

+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| 109299 | mauvaisgapi | 10.0.63.45:58053 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109524 | mauvaisgapi | 10.0.63.47:54005 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109555 | mauvaisgapi | 10.0.63.37:35835 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109646 | mauvaisgapi | 10.0.63.42:41258 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109733 | mauvaisgapi | 10.0.63.42:41306 | mauvaisgapi | Sleep | 0 | | |
| 109738 | mauvaisgapi | 10.0.63.66:36088 | mauvaisgapi | Query | 0 | statistics | SELECT articles.id_article, articles.titre, articles.descriptif, articles.lang
FROM `mauvaisgapi`.sp |
| 109746 | mauvaisgapi | 10.0.63.63:56636 | mauvaisgapi | Query | 0 | removing tmp table | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |

6

Tu utilises peut-être des fonctions pompeuses comme la comparaison d'expressions régulières dans tes boucles pour trouver la correspondance entre le titre de l'article (un bouquin) et le produit oscommerce... Je fais comme ça sur www.vtopo.com (je me suis largement inspiré de ton système de mariage de spip et oscommerce) mais je dois avoir moins de visites que toi !

7

Salut,

ça ressemble à un boucle ARTICLES, avec un critère {id_mot} ou {titre_mot} ou groupe qui est un peu gourmant... tu as cela dans tes squelettes?

Pierre

Bernard Strainchamps wrote:

Bonjour,
J'ai réinstallé la base et une heure plus tard le tueur de base d'ovh a frappé à nouveau !
Je vais simplifier mes requêtes...
Je vais aussi supprimer le cache comme m'a demandé une fois ovh.
L'adresse du site (quand j'aurais réinstaller une nouvelle base), c'est http://www.bibliosurf.com
Qui sait lire les données fournies par ovh ?
Merci de votre aide.
J'en ai bien besoin.
BS

+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| 109299 | mauvaisgapi | 10.0.63.45:58053 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109524 | mauvaisgapi | 10.0.63.47:54005 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109555 | mauvaisgapi | 10.0.63.37:35835 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109646 | mauvaisgapi | 10.0.63.42:41258 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109733 | mauvaisgapi | 10.0.63.42:41306 | mauvaisgapi | Sleep | 0 | | |
| 109738 | mauvaisgapi | 10.0.63.66:36088 | mauvaisgapi | Query | 0 | statistics | SELECT articles.id_article, articles.titre, articles.descriptif, articles.lang
FROM `mauvaisgapi`.sp |
| 109746 | mauvaisgapi | 10.0.63.63:56636 | mauvaisgapi | Query | 0 | removing tmp table | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |

8

Merci pour l'info.
Je crois avoir détecté le squelette qui plante.
Je l'ai simplifié à l'extrême à mon grand regret...
J'ai effectué un gros nettoyage sur les squelettes et même fermé les stats !
Cordialement,
Bernard Strainchamps

Pierre Andrews a écrit :

Salut,

ça ressemble à un boucle ARTICLES, avec un critère {id_mot} ou {titre_mot} ou groupe qui est un peu gourmant... tu as cela dans tes squelettes?

Pierre

Bernard Strainchamps wrote:
  

Bonjour,
J'ai réinstallé la base et une heure plus tard le tueur de base d'ovh a frappé à nouveau !
Je vais simplifier mes requêtes...
Je vais aussi supprimer le cache comme m'a demandé une fois ovh.
L'adresse du site (quand j'aurais réinstaller une nouvelle base), c'est http://www.bibliosurf.com
Qui sait lire les données fournies par ovh ?
Merci de votre aide.
J'en ai bien besoin.
BS

+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| 109299 | mauvaisgapi | 10.0.63.45:58053 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109524 | mauvaisgapi | 10.0.63.47:54005 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109555 | mauvaisgapi | 10.0.63.37:35835 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109646 | mauvaisgapi | 10.0.63.42:41258 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109733 | mauvaisgapi | 10.0.63.42:41306 | mauvaisgapi | Sleep | 0 | | |
| 109738 | mauvaisgapi | 10.0.63.66:36088 | mauvaisgapi | Query | 0 | statistics | SELECT articles.id_article, articles.titre, articles.descriptif, articles.lang
FROM `mauvaisgapi`.sp |
| 109746 | mauvaisgapi | 10.0.63.63:56636 | mauvaisgapi | Query | 0 | removing tmp table | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |

_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : FAQ webmestre - SPIP

9

Je crois avoir détecté le squelette qui posait le plus de problème.
Ce que je comprends pas, c'est qu'il est en place depuis septembre et qu'il n'a jamais aussi peu été consulté !!!
J'ai peur qu'ovh tue une troisième fois ma base.
Cordialement,
BS

Farouba a écrit :

Tu utilises peut-être des fonctions pompeuses comme la comparaison d'expressions régulières dans tes boucles pour trouver la correspondance entre le titre de l'article (un bouquin) et le produit oscommerce... Je fais comme ça sur www.vtopo.com (je me suis largement inspiré de ton système de mariage de spip et oscommerce) mais je dois avoir moins de visites que toi !

_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : FAQ webmestre - SPIP

10

Merci beaucoup : votre piste est vraiment la bonne.
Je vais donc faire la chasse à cette boucle imbriquée que je triai par un titre_mot
Cordialement,
Bernard Strainchamps

Pierre Andrews a écrit :

Salut,

ça ressemble à un boucle ARTICLES, avec un critère {id_mot} ou {titre_mot} ou groupe qui est un peu gourmant... tu as cela dans tes squelettes?

Pierre

Bernard Strainchamps wrote:
  

Bonjour,
J'ai réinstallé la base et une heure plus tard le tueur de base d'ovh a frappé à nouveau !
Je vais simplifier mes requêtes...
Je vais aussi supprimer le cache comme m'a demandé une fois ovh.
L'adresse du site (quand j'aurais réinstaller une nouvelle base), c'est http://www.bibliosurf.com
Qui sait lire les données fournies par ovh ?
Merci de votre aide.
J'en ai bien besoin.
BS

+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+-------------+------------------+-------------+---------+------+--------------------+------------------------------------------------------------------------------------------------------+
| 109299 | mauvaisgapi | 10.0.63.45:58053 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109524 | mauvaisgapi | 10.0.63.47:54005 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109555 | mauvaisgapi | 10.0.63.37:35835 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109646 | mauvaisgapi | 10.0.63.42:41258 | mauvaisgapi | Query | 0 | statistics | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |
| 109733 | mauvaisgapi | 10.0.63.42:41306 | mauvaisgapi | Sleep | 0 | | |
| 109738 | mauvaisgapi | 10.0.63.66:36088 | mauvaisgapi | Query | 0 | statistics | SELECT articles.id_article, articles.titre, articles.descriptif, articles.lang
FROM `mauvaisgapi`.sp |
| 109746 | mauvaisgapi | 10.0.63.63:56636 | mauvaisgapi | Query | 0 | removing tmp table | SELECT mots.id_mot, mots.titre
FROM `mauvaisgapi`.spip_mots_articles AS `L1`, `mauvaisgapi`.spip_mot |

_______________________________________________
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : FAQ webmestre - SPIP

11

Bernard Strainchamps wrote:

Merci beaucoup : votre piste est vraiment la bonne.
Je vais donc faire la chasse à cette boucle imbriquée que je triai par un titre_mot
Cordialement,
Bernard Strainchamps

il faut eviter d'utiliser {id_mot}, {titre_mot}, etc.. sur des boucles ARTICLES et RUBRIQUES, ces critères sont assez gourmant et demande de faire une jointure entre la large table des mots, sur la large table des articles...
Si on l'utilise sans ajouter d'autres contraintes, ça peut demander bcp de calcul à une boucle. Parfois, on peut tout aussi bien utiliser une boucle MOTS suivit d'une boucle ARTICLES et soulager un peu tout cela.

Pierre

12

Le 12 déc. 07 à 17:32, Pierre Andrews a écrit :

il faut eviter d'utiliser {id_mot}, {titre_mot}, etc.. sur des boucles
ARTICLES et RUBRIQUES, ces critères sont assez gourmant et demande de
faire une jointure entre la large table des mots, sur la large table des
articles...

ARGH ! Mais ça fait des mois que j'en truffe mes squelettes !
Impossible de s'en douter quand on est pas un MySQLeur professionnel...
Il faudrait inscrire cette info en lettres capitales (et en rouge) sur la page d'accueil de spip.net !

Je ne comprends pas pourquoi c'est si gourmand, dans la mesure où normalement spip ne calcule cela qu'une fois par jour, et met le résultat en cache ?

Houlala, je déchante, moi :frowning:

13

margranger a écrit :

Le 12 déc. 07 à 17:32, Pierre Andrews a écrit :

il faut eviter d'utiliser {id_mot}, {titre_mot}, etc.. sur des boucles
ARTICLES et RUBRIQUES, ces critères sont assez gourmant et demande de
faire une jointure entre la large table des mots, sur la large table des
articles...

ARGH ! Mais ça fait des mois que j'en truffe mes squelettes !
Impossible de s'en douter quand on est pas un MySQLeur professionnel...
Il faudrait inscrire cette info en lettres capitales (et en rouge) sur la page d'accueil de spip.net !

meuh non, c'est pas si catastrophique que ca quand meme !
{id_mot} ajoute une jointure, {titre_mot} et {type_mot} mais c'est sur des champs indexés.

ce qu'il faut surtout eviter, c'est les regexp comme {champ==^xxx}, et ca encore plus si il y a des jointures.

Si tu veux voir le temps de calcul MySQL, ajoute ?var_profile (ou &var_profile si il y a des parametres) à la fin de ton url en étant authentifié en admin.

Si des requetes commencent à se rapprocher de la seconde, il faut peut etre verifier les indexes, il en manque peut etre un important (en particulier les champs titre et type de spip_mots).

Je ne comprends pas pourquoi c'est si gourmand, dans la mesure où normalement spip ne calcule cela qu'une fois par jour, et met le résultat en cache ?

oui, et c'est surement de ce coté qu'il faut regarder, qu'il n'y ait pas un #CACHE{0} qui traine ou une inclusion avec {date} ou un parametre qui change dans le contexte.

Le cache joue tres bien son role, mais l'hebergeur qui fait la chasse aux sites gourmands va penser que spip est tres gourmand parce qu'un hit peut generer beaucoup de calculs et de requetes.
Mais la majorité des hits génère une charge minimum (meme les stats ne provoquent pas de hit systematique).

Houlala, je déchante, moi :frowning:

Il y a des gros sites sous spip et ils ne se privent pas des mots clés.

@++

14

margranger wrote:

Le 12 déc. 07 à 17:32, Pierre Andrews a écrit :

il faut eviter d'utiliser {id_mot}, {titre_mot}, etc.. sur des boucles
ARTICLES et RUBRIQUES, ces critères sont assez gourmant et demande de
faire une jointure entre la large table des mots, sur la large table des
articles...

ARGH ! Mais ça fait des mois que j'en truffe mes squelettes !
Impossible de s'en douter quand on est pas un MySQLeur professionnel...
Il faudrait inscrire cette info en lettres capitales (et en rouge) sur la page d'accueil de spip.net !

bon, g pas dit que ça allait faire exploser ton serveur à chaque coup, si ct vraiment dangereux, ce serait pas là.... mais si tu fais pas attention, bah tu peux faire des choses mauvaises.

Si tu as 3000 articles et 200 mots, bin:
<BOUCLE_art(ARTICLES) {par titre_mot}>
sera assez méchant parce que ça fait une jointure assez grosse...

Je ne comprends pas pourquoi c'est si gourmand, dans la mesure où normalement spip ne calcule cela qu'une fois par jour, et met le résultat en cache ?

voilà, il faut bien faire attention au cache. En plus, il faut se poser la question, à quoi ça sert de recalculer une page une fois par jour? un article, une fois ecrit, ça change pas si souvent que ça...

Pierre

15

Le 12 déc. 07 à 19:31, Pierre Andrews a écrit :

bon, g pas dit que ça allait faire exploser ton serveur à chaque coup,
si ct vraiment dangereux, ce serait pas là.... mais si tu fais pas
attention, bah tu peux faire des choses mauvaises.

Si tu as 3000 articles et 200 mots, bin:
<BOUCLE_art(ARTICLES) {par titre_mot}>
sera assez méchant parce que ça fait une jointure assez grosse...

OK je comprends un peu mieux, y a rien de grave.
Mais c'est intéressant quand même :

Du coup, faut-il comprendre que ma boucle
<BOUCLE_a_la_une(ARTICLES){titre_mot=une} >

gagnerait à être remplacée par un truc du style
<BOUCLE_a_la_une(MOTS){titre_mot=une}>
<BOUCLE_article(ARTICLES){id_mot}>
</BOUCLE_a_la_une>

?

16

margranger a écrit :

Le 12 déc. 07 à 19:31, Pierre Andrews a écrit :

bon, g pas dit que ça allait faire exploser ton serveur à chaque coup,
si ct vraiment dangereux, ce serait pas là.... mais si tu fais pas
attention, bah tu peux faire des choses mauvaises.

Si tu as 3000 articles et 200 mots, bin:
<BOUCLE_art(ARTICLES) {par titre_mot}>
sera assez méchant parce que ça fait une jointure assez grosse...

OK je comprends un peu mieux, y a rien de grave.
Mais c'est intéressant quand même :

Du coup, faut-il comprendre que ma boucle
<BOUCLE_a_la_une(ARTICLES){titre_mot=une} >

gagnerait à être remplacée par un truc du style
<BOUCLE_a_la_une(MOTS){titre_mot=une}>
<BOUCLE_article(ARTICLES){id_mot}>
</BOUCLE_a_la_une>

elle ne "gagnerait" pas, mais ca passerait sans doute entre les mailles du filet de l'hébergeur qui chasse le client "pas rentable".

Mais sincerement, un hebergeur qui fait ca, il faut en changer, c'est tout : chez free ca a l'air mieux que ca !

@++