bonjour,
j'ai un site heberge chez online,
depuis quelques jous les pages s'ouvrent: aleatoirement rapidement ou
lentement, voir plante ?
cela sur plusieurs pc, mais ca le fait que sur mon site ?
y a des tests a faire ?
suis debutant, explications softs
merci
amities
Pareil pour mes sites, et cela depuis une semaine.
Pareil également pour moi. C'est pas la première fois, mais là, record battu :(
J'avais envoyé un mail il y a quelque temps : On m'a répondu que c'était dû au serveur mutualisé. Si l'un pique trop sur la bande passante, c'est au détriment des autres.
... bien envie de migrer quand même...
Aujourd'hui, ça marche.
-- Alain Mest : http://www.aidewindows.net EFG : http://efg.aidemac.net
"Scotty" a écrit dans le message de news:
mn.14ac7d64a66e0ec5.48735@wanatoudou.fr...
Pareil pour mes sites, et cela depuis une semaine.
Pareil également pour moi.
C'est pas la première fois, mais là, record battu :(
J'avais envoyé un mail il y a quelque temps : On m'a répondu que c'était
dû au serveur mutualisé. Si l'un pique trop sur la bande passante, c'est
au détriment des autres.
... bien envie de migrer quand même...
Aujourd'hui, ça marche.
--
Alain Mest : http://www.aidewindows.net
EFG : http://efg.aidemac.net
Pareil pour mes sites, et cela depuis une semaine.
Pareil également pour moi. C'est pas la première fois, mais là, record battu :(
J'avais envoyé un mail il y a quelque temps : On m'a répondu que c'était dû au serveur mutualisé. Si l'un pique trop sur la bande passante, c'est au détriment des autres.
... bien envie de migrer quand même...
Aujourd'hui, ça marche.
-- Alain Mest : http://www.aidewindows.net EFG : http://efg.aidemac.net
Scotty
"Scotty" a écrit dans le message de news:
Pareil pour mes sites, et cela depuis une semaine.
Pareil également pour moi. C'est pas la première fois, mais là, record battu :(
J'avais envoyé un mail il y a quelque temps : On m'a répondu que c'était dû au serveur mutualisé. Si l'un pique trop sur la bande passante, c'est au détriment des autres.
... bien envie de migrer quand même...
Aujourd'hui, ça marche.
Salut,
Pour ma part, ils ont répondu qu'ils avaient rencontré un problème sur un des serveurs MySql le 26/03 et que cela a entrainé des surcharges en cascade sur d'autres serveurs. 26/03, cela correspond à la date à partir de laquelle mes soucis ont commencé.
Je cite "Actuellement, de nouveaux serveurs sont en déploiement pour résorber la congestion". Croisons les doigts !
A+
-- J'ai la nette impression que nous sommes sur la meme longueur d'ondes bien que sur ce point je peux affirmer avec certitude le contraire.
"Scotty" a écrit dans le message de news:
mn.14ac7d64a66e0ec5.48735@wanatoudou.fr...
Pareil pour mes sites, et cela depuis une semaine.
Pareil également pour moi.
C'est pas la première fois, mais là, record battu :(
J'avais envoyé un mail il y a quelque temps : On m'a répondu que c'était
dû au serveur mutualisé. Si l'un pique trop sur la bande passante, c'est
au détriment des autres.
... bien envie de migrer quand même...
Aujourd'hui, ça marche.
Salut,
Pour ma part, ils ont répondu qu'ils avaient rencontré un problème sur
un des serveurs MySql le 26/03 et que cela a entrainé des surcharges en
cascade sur d'autres serveurs.
26/03, cela correspond à la date à partir de laquelle mes soucis ont
commencé.
Je cite "Actuellement, de nouveaux serveurs sont en déploiement pour
résorber la congestion". Croisons les doigts !
A+
--
J'ai la nette impression que nous sommes sur la meme longueur d'ondes
bien que sur ce point je peux affirmer avec certitude le contraire.
Pareil pour mes sites, et cela depuis une semaine.
Pareil également pour moi. C'est pas la première fois, mais là, record battu :(
J'avais envoyé un mail il y a quelque temps : On m'a répondu que c'était dû au serveur mutualisé. Si l'un pique trop sur la bande passante, c'est au détriment des autres.
... bien envie de migrer quand même...
Aujourd'hui, ça marche.
Salut,
Pour ma part, ils ont répondu qu'ils avaient rencontré un problème sur un des serveurs MySql le 26/03 et que cela a entrainé des surcharges en cascade sur d'autres serveurs. 26/03, cela correspond à la date à partir de laquelle mes soucis ont commencé.
Je cite "Actuellement, de nouveaux serveurs sont en déploiement pour résorber la congestion". Croisons les doigts !
A+
-- J'ai la nette impression que nous sommes sur la meme longueur d'ondes bien que sur ce point je peux affirmer avec certitude le contraire.
Frédéric VANNIÈRE
Scotty wrote:
Pour ma part, ils ont répondu qu'ils avaient rencontré un problème sur un des serveurs MySql le 26/03 et que cela a entrainé des surcharges en cascade sur d'autres serveurs. 26/03, cela correspond à la date à partir de laquelle mes soucis ont commencé.
Je cite "Actuellement, de nouveaux serveurs sont en déploiement pour résorber la congestion". Croisons les doigts !
MySQL est le service le plus compliqué pour un hébergeur. Il faut des machines très puissantes (nous on a 2 BI-Opterons avec des disques ultra-rapides). On ne peut pas faire de cluster à moins de dépenser des fortunes et un seul client peut mettre à genoux un serveur.
En plus, on n'a aucune information sur l'utilisation faite par les clients, on peut limiter le nombre de requêtes par secondes, heures ... mais pas savoir combien en fait un utilisateur.
Frédéric.
-- Frédéric VANNIERE 231 rue Saint-Honoré Directeur Technique 75001 PARIS - FRANCE PLANET-WORK Tél : 0891 024 424 http://www.planet-work.com Fax : 0143 461 199
Scotty wrote:
Pour ma part, ils ont répondu qu'ils avaient rencontré un problème sur
un des serveurs MySql le 26/03 et que cela a entrainé des surcharges en
cascade sur d'autres serveurs.
26/03, cela correspond à la date à partir de laquelle mes soucis ont
commencé.
Je cite "Actuellement, de nouveaux serveurs sont en déploiement pour
résorber la congestion". Croisons les doigts !
MySQL est le service le plus compliqué pour un hébergeur. Il faut
des machines très puissantes (nous on a 2 BI-Opterons avec des
disques ultra-rapides). On ne peut pas faire de cluster à moins
de dépenser des fortunes et un seul client peut mettre à genoux un
serveur.
En plus, on n'a aucune information sur l'utilisation faite par les
clients, on peut limiter le nombre de requêtes par secondes, heures ...
mais pas savoir combien en fait un utilisateur.
Frédéric.
--
Frédéric VANNIERE 231 rue Saint-Honoré
Directeur Technique 75001 PARIS - FRANCE
PLANET-WORK Tél : 0891 024 424
http://www.planet-work.com Fax : 0143 461 199
Pour ma part, ils ont répondu qu'ils avaient rencontré un problème sur un des serveurs MySql le 26/03 et que cela a entrainé des surcharges en cascade sur d'autres serveurs. 26/03, cela correspond à la date à partir de laquelle mes soucis ont commencé.
Je cite "Actuellement, de nouveaux serveurs sont en déploiement pour résorber la congestion". Croisons les doigts !
MySQL est le service le plus compliqué pour un hébergeur. Il faut des machines très puissantes (nous on a 2 BI-Opterons avec des disques ultra-rapides). On ne peut pas faire de cluster à moins de dépenser des fortunes et un seul client peut mettre à genoux un serveur.
En plus, on n'a aucune information sur l'utilisation faite par les clients, on peut limiter le nombre de requêtes par secondes, heures ... mais pas savoir combien en fait un utilisateur.
Frédéric.
-- Frédéric VANNIERE 231 rue Saint-Honoré Directeur Technique 75001 PARIS - FRANCE PLANET-WORK Tél : 0891 024 424 http://www.planet-work.com Fax : 0143 461 199
-jl-
"Frédéric VANNIÈRE" a écrit dans le message de news: 4432229a$0$9634$
Scotty wrote:
Pour ma part, ils ont répondu qu'ils avaient rencontré un problème sur un des serveurs MySql le 26/03 et que cela a entrainé des surcharges en cascade sur d'autres serveurs. 26/03, cela correspond à la date à partir de laquelle mes soucis ont commencé.
Je cite "Actuellement, de nouveaux serveurs sont en déploiement pour résorber la congestion". Croisons les doigts !
MySQL est le service le plus compliqué pour un hébergeur. Il faut des machines très puissantes (nous on a 2 BI-Opterons avec des disques ultra-rapides). On ne peut pas faire de cluster à moins de dépenser des fortunes et un seul client peut mettre à genoux un serveur.
En plus, on n'a aucune information sur l'utilisation faite par les clients, on peut limiter le nombre de requêtes par secondes, heures ... mais pas savoir combien en fait un utilisateur.
hum !
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas crier après aussi.
-jl-
"Frédéric VANNIÈRE" <f.vanniere@planet-work.com> a écrit dans le message de
news: 4432229a$0$9634$636a55ce@news.free.fr...
Scotty wrote:
Pour ma part, ils ont répondu qu'ils avaient rencontré un problème sur
un des serveurs MySql le 26/03 et que cela a entrainé des surcharges en
cascade sur d'autres serveurs.
26/03, cela correspond à la date à partir de laquelle mes soucis ont
commencé.
Je cite "Actuellement, de nouveaux serveurs sont en déploiement pour
résorber la congestion". Croisons les doigts !
MySQL est le service le plus compliqué pour un hébergeur. Il faut
des machines très puissantes (nous on a 2 BI-Opterons avec des
disques ultra-rapides). On ne peut pas faire de cluster à moins
de dépenser des fortunes et un seul client peut mettre à genoux un
serveur.
En plus, on n'a aucune information sur l'utilisation faite par les
clients, on peut limiter le nombre de requêtes par secondes, heures ...
mais pas savoir combien en fait un utilisateur.
hum !
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je
l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant
mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et
spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire
sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas
crier après aussi.
"Frédéric VANNIÈRE" a écrit dans le message de news: 4432229a$0$9634$
Scotty wrote:
Pour ma part, ils ont répondu qu'ils avaient rencontré un problème sur un des serveurs MySql le 26/03 et que cela a entrainé des surcharges en cascade sur d'autres serveurs. 26/03, cela correspond à la date à partir de laquelle mes soucis ont commencé.
Je cite "Actuellement, de nouveaux serveurs sont en déploiement pour résorber la congestion". Croisons les doigts !
MySQL est le service le plus compliqué pour un hébergeur. Il faut des machines très puissantes (nous on a 2 BI-Opterons avec des disques ultra-rapides). On ne peut pas faire de cluster à moins de dépenser des fortunes et un seul client peut mettre à genoux un serveur.
En plus, on n'a aucune information sur l'utilisation faite par les clients, on peut limiter le nombre de requêtes par secondes, heures ... mais pas savoir combien en fait un utilisateur.
hum !
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas crier après aussi.
-jl-
Frédéric VANNIÈRE
-jl- wrote:
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas crier après aussi.
Sur un serveur on a 2200 bases de données utilisées, c'est un Dual-Opteron 2 GHz, 4 Go RAM et SCSI 15 krpm en RAID-10. Le serveur est chargé correctement mais si un client fait n'importe quoi ça peut vite le faire monter. On est obligé de surveiller les requêtes SQL trop longues.
Il gère en moyenne 500 requêtes par secondes, ca veut dire qu'il monte à 800/1000 en pointe. Les disques durs sont peu utilisés, là ou ça bloque c'est au niveau de la puissance CPU.
Si les clients savaient créer des indexes et faire proprement des requêtes SQL il n'y aurait aucun problème.
Frédéric.
-- Frédéric VANNIERE 231 rue Saint-Honoré Directeur Technique 75001 PARIS - FRANCE PLANET-WORK Tél : 0891 024 424 http://www.planet-work.com Fax : 0143 461 199
-jl- wrote:
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je
l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant
mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et
spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire
sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas
crier après aussi.
Sur un serveur on a 2200 bases de données utilisées, c'est un
Dual-Opteron 2 GHz, 4 Go RAM et SCSI 15 krpm en RAID-10.
Le serveur est chargé correctement mais si un client fait n'importe
quoi ça peut vite le faire monter. On est obligé de surveiller
les requêtes SQL trop longues.
Il gère en moyenne 500 requêtes par secondes, ca veut dire qu'il
monte à 800/1000 en pointe. Les disques durs sont peu utilisés,
là ou ça bloque c'est au niveau de la puissance CPU.
Si les clients savaient créer des indexes et faire proprement
des requêtes SQL il n'y aurait aucun problème.
Frédéric.
--
Frédéric VANNIERE 231 rue Saint-Honoré
Directeur Technique 75001 PARIS - FRANCE
PLANET-WORK Tél : 0891 024 424
http://www.planet-work.com Fax : 0143 461 199
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas crier après aussi.
Sur un serveur on a 2200 bases de données utilisées, c'est un Dual-Opteron 2 GHz, 4 Go RAM et SCSI 15 krpm en RAID-10. Le serveur est chargé correctement mais si un client fait n'importe quoi ça peut vite le faire monter. On est obligé de surveiller les requêtes SQL trop longues.
Il gère en moyenne 500 requêtes par secondes, ca veut dire qu'il monte à 800/1000 en pointe. Les disques durs sont peu utilisés, là ou ça bloque c'est au niveau de la puissance CPU.
Si les clients savaient créer des indexes et faire proprement des requêtes SQL il n'y aurait aucun problème.
Frédéric.
-- Frédéric VANNIERE 231 rue Saint-Honoré Directeur Technique 75001 PARIS - FRANCE PLANET-WORK Tél : 0891 024 424 http://www.planet-work.com Fax : 0143 461 199
FightClub!
"Frédéric VANNIÈRE" a écrit dans le message de news: 4432229a$0$9634$
Scotty wrote:
hum !
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant
je veux bien que tu le retrouves, parce que à ma connaissance et compte-tenu des infos fournies par mysql (en particulier le fait de n'avoir aucune possibilité de connaitre la charge d'un utilisateur précis), le script va couter en ressource à peu pres autant que la surcharge qu'il va traiter, donc il ne sert à rien.
mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire
Il n'y a pourtant rien de plus simple (façon de parler). On fait plus ou moins 35000 requetes/minutes sur une base de environ 3 millions d'enregistrements, en optimisant à fond les requetes, aucune jointure, les bons index et tout sur un bi-pro scsi 10000tr 4Go, et pourtant, en mutualisé, il tombe vite fait.
sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas crier après aussi.
C'est bien tout le probleme de MySQL : 3 jointures mal faites, aucun index dans des tables de quelques milliers d'enregistrement, et avec la même machine on peut faire tomber le serveur dès 2000 requetes/minutes. Et c'est exactement ce qui arrive sur le mutualisé (ou alors faut vraiment avoir du bol et tomber sur des bons clients !).
"Frédéric VANNIÈRE" <f.vanniere@planet-work.com> a écrit dans le message de
news: 4432229a$0$9634$636a55ce@news.free.fr...
Scotty wrote:
hum !
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je
l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant
je veux bien que tu le retrouves, parce que à ma connaissance et
compte-tenu des infos fournies par mysql (en particulier le fait de
n'avoir aucune possibilité de connaitre la charge d'un utilisateur
précis), le script va couter en ressource à peu pres autant que la
surcharge qu'il va traiter, donc il ne sert à rien.
mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et
spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire
Il n'y a pourtant rien de plus simple (façon de parler). On fait plus ou
moins 35000 requetes/minutes sur une base de environ 3 millions
d'enregistrements, en optimisant à fond les requetes, aucune jointure,
les bons index et tout sur un bi-pro scsi 10000tr 4Go, et pourtant, en
mutualisé, il tombe vite fait.
sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas
crier après aussi.
C'est bien tout le probleme de MySQL : 3 jointures mal faites, aucun
index dans des tables de quelques milliers d'enregistrement, et avec la
même machine on peut faire tomber le serveur dès 2000 requetes/minutes.
Et c'est exactement ce qui arrive sur le mutualisé (ou alors faut
vraiment avoir du bol et tomber sur des bons clients !).
"Frédéric VANNIÈRE" a écrit dans le message de news: 4432229a$0$9634$
Scotty wrote:
hum !
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant
je veux bien que tu le retrouves, parce que à ma connaissance et compte-tenu des infos fournies par mysql (en particulier le fait de n'avoir aucune possibilité de connaitre la charge d'un utilisateur précis), le script va couter en ressource à peu pres autant que la surcharge qu'il va traiter, donc il ne sert à rien.
mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire
Il n'y a pourtant rien de plus simple (façon de parler). On fait plus ou moins 35000 requetes/minutes sur une base de environ 3 millions d'enregistrements, en optimisant à fond les requetes, aucune jointure, les bons index et tout sur un bi-pro scsi 10000tr 4Go, et pourtant, en mutualisé, il tombe vite fait.
sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas crier après aussi.
C'est bien tout le probleme de MySQL : 3 jointures mal faites, aucun index dans des tables de quelques milliers d'enregistrement, et avec la même machine on peut faire tomber le serveur dès 2000 requetes/minutes. Et c'est exactement ce qui arrive sur le mutualisé (ou alors faut vraiment avoir du bol et tomber sur des bons clients !).
Frédéric VANNIÈRE
FightClub! wrote:
C'est bien tout le probleme de MySQL : 3 jointures mal faites, aucun index dans des tables de quelques milliers d'enregistrement, et avec la même machine on peut faire tomber le serveur dès 2000 requetes/minutes. Et c'est exactement ce qui arrive sur le mutualisé (ou alors faut vraiment avoir du bol et tomber sur des bons clients !).
Dans MySQL 4 on peut logger les requêtes trop longues (plus de 10 secondes). C'est bien mais pas suffisant, j'aimerai bien passer à MySQL 5 car maintenant on peut logger les requêtes qui n'utilisent pas les indexes dans le but de tirer les oreilles du client.
Malheureusement passer plus de 2000 BDD en MySQL 5 c'est risqué, ça peut casser pas mal de sites.
Frédéric.
-- Frédéric VANNIERE 231 rue Saint-Honoré Directeur Technique 75001 PARIS - FRANCE PLANET-WORK Tél : 0891 024 424 http://www.planet-work.com Fax : 0143 461 199
FightClub! wrote:
C'est bien tout le probleme de MySQL : 3 jointures mal faites, aucun
index dans des tables de quelques milliers d'enregistrement, et avec la
même machine on peut faire tomber le serveur dès 2000 requetes/minutes.
Et c'est exactement ce qui arrive sur le mutualisé (ou alors faut
vraiment avoir du bol et tomber sur des bons clients !).
Dans MySQL 4 on peut logger les requêtes trop longues (plus
de 10 secondes). C'est bien mais pas suffisant, j'aimerai
bien passer à MySQL 5 car maintenant on peut logger les
requêtes qui n'utilisent pas les indexes dans le but de
tirer les oreilles du client.
Malheureusement passer plus de 2000 BDD en MySQL 5 c'est
risqué, ça peut casser pas mal de sites.
Frédéric.
--
Frédéric VANNIERE 231 rue Saint-Honoré
Directeur Technique 75001 PARIS - FRANCE
PLANET-WORK Tél : 0891 024 424
http://www.planet-work.com Fax : 0143 461 199
C'est bien tout le probleme de MySQL : 3 jointures mal faites, aucun index dans des tables de quelques milliers d'enregistrement, et avec la même machine on peut faire tomber le serveur dès 2000 requetes/minutes. Et c'est exactement ce qui arrive sur le mutualisé (ou alors faut vraiment avoir du bol et tomber sur des bons clients !).
Dans MySQL 4 on peut logger les requêtes trop longues (plus de 10 secondes). C'est bien mais pas suffisant, j'aimerai bien passer à MySQL 5 car maintenant on peut logger les requêtes qui n'utilisent pas les indexes dans le but de tirer les oreilles du client.
Malheureusement passer plus de 2000 BDD en MySQL 5 c'est risqué, ça peut casser pas mal de sites.
Frédéric.
-- Frédéric VANNIERE 231 rue Saint-Honoré Directeur Technique 75001 PARIS - FRANCE PLANET-WORK Tél : 0891 024 424 http://www.planet-work.com Fax : 0143 461 199
-jl-
"Frédéric VANNIÈRE" a écrit dans le message de news: 4432689a$0$12280$
-jl- wrote:
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas crier après aussi.
Sur un serveur on a 2200 bases de données utilisées, c'est un Dual-Opteron 2 GHz, 4 Go RAM et SCSI 15 krpm en RAID-10. Le serveur est chargé correctement mais si un client fait n'importe quoi ça peut vite le faire monter. On est obligé de surveiller les requêtes SQL trop longues.
ba simple à faire un smple script php ou mieux en shell chéquant les requetes et qui kill par exemple le requête de plus de 20 secondes, mysql dispose d'instruction pour cela
Il gère en moyenne 500 requêtes par secondes, ca veut dire qu'il monte à 800/1000 en pointe. Les disques durs sont peu utilisés, là ou ça bloque c'est au niveau de la puissance CPU.
? ha ben tu doit avoir un blème quelque part, j'ai toujours vu un problème de lenteur du au disque voir à la ram jamais au processeur
Si les clients savaient créer des indexes et faire proprement des requêtes SQL il n'y aurait aucun problème.
ca c'est vrai
-jl-
"Frédéric VANNIÈRE" <f.vanniere@planet-work.com> a écrit dans le message de
news: 4432689a$0$12280$626a54ce@news.free.fr...
-jl- wrote:
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je
l'ai mit, mais bon cela doit pas être très difficile à refaire,
maintenant
mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et
spécifiquement dédié à mysql faut le faire et la personne n'a rien à
faire
sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas
crier après aussi.
Sur un serveur on a 2200 bases de données utilisées, c'est un
Dual-Opteron 2 GHz, 4 Go RAM et SCSI 15 krpm en RAID-10.
Le serveur est chargé correctement mais si un client fait n'importe
quoi ça peut vite le faire monter. On est obligé de surveiller
les requêtes SQL trop longues.
ba simple à faire un smple script php ou mieux en shell chéquant les
requetes et qui kill par exemple le requête de plus de 20 secondes, mysql
dispose d'instruction pour cela
Il gère en moyenne 500 requêtes par secondes, ca veut dire qu'il
monte à 800/1000 en pointe. Les disques durs sont peu utilisés,
là ou ça bloque c'est au niveau de la puissance CPU.
? ha ben tu doit avoir un blème quelque part, j'ai toujours vu un problème
de lenteur du au disque voir à la ram jamais au processeur
Si les clients savaient créer des indexes et faire proprement
des requêtes SQL il n'y aurait aucun problème.
"Frédéric VANNIÈRE" a écrit dans le message de news: 4432689a$0$12280$
-jl- wrote:
j'ai à l'époque fait un script qui gérait tout ça mais je sais plus ou je l'ai mit, mais bon cela doit pas être très difficile à refaire, maintenant mettre à genou un bi pro sur du scsi avec disons 2 à 4 go de ram et spécifiquement dédié à mysql faut le faire et la personne n'a rien à faire sur du mutu à ce niveau, maintenant si tu as 50 000 base dessus faut pas crier après aussi.
Sur un serveur on a 2200 bases de données utilisées, c'est un Dual-Opteron 2 GHz, 4 Go RAM et SCSI 15 krpm en RAID-10. Le serveur est chargé correctement mais si un client fait n'importe quoi ça peut vite le faire monter. On est obligé de surveiller les requêtes SQL trop longues.
ba simple à faire un smple script php ou mieux en shell chéquant les requetes et qui kill par exemple le requête de plus de 20 secondes, mysql dispose d'instruction pour cela
Il gère en moyenne 500 requêtes par secondes, ca veut dire qu'il monte à 800/1000 en pointe. Les disques durs sont peu utilisés, là ou ça bloque c'est au niveau de la puissance CPU.
? ha ben tu doit avoir un blème quelque part, j'ai toujours vu un problème de lenteur du au disque voir à la ram jamais au processeur
Si les clients savaient créer des indexes et faire proprement des requêtes SQL il n'y aurait aucun problème.
ca c'est vrai
-jl-
-jl-
"FightClub!" a écrit dans le message de news: 443268f9$0$21263$
je veux bien que tu le retrouves, parce que à ma connaissance et compte-tenu des infos fournies par mysql (en particulier le fait de n'avoir aucune possibilité de connaitre la charge d'un utilisateur précis), le script va couter en ressource à peu pres autant que la surcharge qu'il va traiter, donc il ne sert à rien.
mon script était en php, mais bon pas difficle le transformer en c ou en
shell, faudra que je regarde sur les archives je l'avais fait à l'epoque ou certains serveurs mysql plantés régulièrement a cause de requête trop longue a la suite plus de problème à ce niveau, on pouvait régler la durée maxi d'une requête avant de la killer etc..., il y avait même un module chéquant les requêtes, le nombre de requête fait par un client etc ...., vais rechercher cela si ca t'interessse
-jl-
"FightClub!" <ng@sd2i.com> a écrit dans le message de news:
443268f9$0$21263$8fcfb975@news.wanadoo.fr...
je veux bien que tu le retrouves, parce que à ma connaissance et
compte-tenu des infos fournies par mysql (en particulier le fait de
n'avoir aucune possibilité de connaitre la charge d'un utilisateur
précis), le script va couter en ressource à peu pres autant que la
surcharge qu'il va traiter, donc il ne sert à rien.
mon script était en php, mais bon pas difficle le transformer en c ou en
shell, faudra que je regarde sur les archives je l'avais fait à l'epoque ou
certains serveurs mysql plantés régulièrement a cause de requête trop
longue a la suite plus de problème à ce niveau, on pouvait régler la durée
maxi d'une requête avant de la killer etc..., il y avait même un module
chéquant les requêtes, le nombre de requête fait par un client etc ....,
vais rechercher cela si ca t'interessse
"FightClub!" a écrit dans le message de news: 443268f9$0$21263$
je veux bien que tu le retrouves, parce que à ma connaissance et compte-tenu des infos fournies par mysql (en particulier le fait de n'avoir aucune possibilité de connaitre la charge d'un utilisateur précis), le script va couter en ressource à peu pres autant que la surcharge qu'il va traiter, donc il ne sert à rien.
mon script était en php, mais bon pas difficle le transformer en c ou en
shell, faudra que je regarde sur les archives je l'avais fait à l'epoque ou certains serveurs mysql plantés régulièrement a cause de requête trop longue a la suite plus de problème à ce niveau, on pouvait régler la durée maxi d'une requête avant de la killer etc..., il y avait même un module chéquant les requêtes, le nombre de requête fait par un client etc ...., vais rechercher cela si ca t'interessse
-jl-
FightClub!
FightClub! wrote:
C'est bien tout le probleme de MySQL : 3 jointures mal faites, aucun index dans des tables de quelques milliers d'enregistrement, et avec la même machine on peut faire tomber le serveur dès 2000 requetes/minutes. Et c'est exactement ce qui arrive sur le mutualisé (ou alors faut vraiment avoir du bol et tomber sur des bons clients !).
Dans MySQL 4 on peut logger les requêtes trop longues (plus de 10 secondes). C'est bien mais pas suffisant, j'aimerai bien passer à MySQL 5 car maintenant on peut logger les requêtes qui n'utilisent pas les indexes dans le but de tirer les oreilles du client.
En 4.1 c'est faisable aussi (log_slow_query pour les requetes lentes, et log_long_query pour les requetes sans index je crois), et passer de 4.0 a 4.1 ne nous a posé aucun problème sur +/- 1800 bdd (juste le format des mots de pass qui change mais un parametre permet la compatibilité arrière)
Sans un bench temps réel du cpu utilisé par l'utilisateur je vois mal comment faire bien la chose, vu qu'un user peut très bien faire 2 requetes/minutes et consommer plus que celui qui en fait 100/minute. Ou alors il faudrait pouvoir carrément interdire les requetes mal écrites ;)
Malheureusement passer plus de 2000 BDD en MySQL 5 c'est risqué, ça peut casser pas mal de sites.
C'est sur !
Frédéric.
FightClub! wrote:
C'est bien tout le probleme de MySQL : 3 jointures mal faites, aucun
index dans des tables de quelques milliers d'enregistrement, et avec la
même machine on peut faire tomber le serveur dès 2000 requetes/minutes.
Et c'est exactement ce qui arrive sur le mutualisé (ou alors faut
vraiment avoir du bol et tomber sur des bons clients !).
Dans MySQL 4 on peut logger les requêtes trop longues (plus
de 10 secondes). C'est bien mais pas suffisant, j'aimerai
bien passer à MySQL 5 car maintenant on peut logger les
requêtes qui n'utilisent pas les indexes dans le but de
tirer les oreilles du client.
En 4.1 c'est faisable aussi (log_slow_query pour les requetes lentes, et
log_long_query pour les requetes sans index je crois), et passer de 4.0
a 4.1 ne nous a posé aucun problème sur +/- 1800 bdd (juste le format
des mots de pass qui change mais un parametre permet la compatibilité
arrière)
Sans un bench temps réel du cpu utilisé par l'utilisateur je vois mal
comment faire bien la chose, vu qu'un user peut très bien faire 2
requetes/minutes et consommer plus que celui qui en fait 100/minute.
Ou alors il faudrait pouvoir carrément interdire les requetes mal écrites ;)
Malheureusement passer plus de 2000 BDD en MySQL 5 c'est
risqué, ça peut casser pas mal de sites.
C'est bien tout le probleme de MySQL : 3 jointures mal faites, aucun index dans des tables de quelques milliers d'enregistrement, et avec la même machine on peut faire tomber le serveur dès 2000 requetes/minutes. Et c'est exactement ce qui arrive sur le mutualisé (ou alors faut vraiment avoir du bol et tomber sur des bons clients !).
Dans MySQL 4 on peut logger les requêtes trop longues (plus de 10 secondes). C'est bien mais pas suffisant, j'aimerai bien passer à MySQL 5 car maintenant on peut logger les requêtes qui n'utilisent pas les indexes dans le but de tirer les oreilles du client.
En 4.1 c'est faisable aussi (log_slow_query pour les requetes lentes, et log_long_query pour les requetes sans index je crois), et passer de 4.0 a 4.1 ne nous a posé aucun problème sur +/- 1800 bdd (juste le format des mots de pass qui change mais un parametre permet la compatibilité arrière)
Sans un bench temps réel du cpu utilisé par l'utilisateur je vois mal comment faire bien la chose, vu qu'un user peut très bien faire 2 requetes/minutes et consommer plus que celui qui en fait 100/minute. Ou alors il faudrait pouvoir carrément interdire les requetes mal écrites ;)
Malheureusement passer plus de 2000 BDD en MySQL 5 c'est risqué, ça peut casser pas mal de sites.
