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
chéquant les requêtes, le nombre de requête fait par un client etc ....,
ça m'intéresse plus que tout le reste (car le reste on fait déjà), parce que à moins de logguer toutes les requetes dans un disque ram et de compter les lignes qui passent pour chaque user, je vois pas comment c'est faisable avec mysql (à moins que tu parles de compter les requetes lentes par utilisateur ?)
vais rechercher cela si ca t'interessse
j'veux pas abuser non plus, mais voui si tu trouves, je prends ;)
-jl-
chéquant les requêtes, le nombre de requête fait par un client etc ....,
ça m'intéresse plus que tout le reste (car le reste on fait déjà), parce
que à moins de logguer toutes les requetes dans un disque ram et de
compter les lignes qui passent pour chaque user, je vois pas comment
c'est faisable avec mysql
(à moins que tu parles de compter les requetes lentes par utilisateur ?)
vais rechercher cela si ca t'interessse
j'veux pas abuser non plus, mais voui si tu trouves, je prends ;)
chéquant les requêtes, le nombre de requête fait par un client etc ....,
ça m'intéresse plus que tout le reste (car le reste on fait déjà), parce que à moins de logguer toutes les requetes dans un disque ram et de compter les lignes qui passent pour chaque user, je vois pas comment c'est faisable avec mysql (à moins que tu parles de compter les requetes lentes par utilisateur ?)
vais rechercher cela si ca t'interessse
j'veux pas abuser non plus, mais voui si tu trouves, je prends ;)
-jl-
Snarf
On 2006-04-04, Frédéric VANNIÈRE wrote:
Si les clients savaient créer des indexes et faire proprement des requêtes SQL il n'y aurait aucun problème. rhaa les clients ;)
les deux plus beau que j'ai vu c'est - un requete générée recursivement de 3Mo (la requete). MySQL a fuit (MySQL has gone away)
- une nouvelle impletation en java de la commande SQL count (a soivoir un select * suivit d'un comptage en java)
rhaa .. ils sont du courage nos serveurs.
heureusement qu'ils n'ont pas de conscience, il ferait la grève sinon ;)
Snarf
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
On 2006-04-04, Frédéric VANNIÈRE <f.vanniere@planet-work.com> wrote:
Si les clients savaient créer des indexes et faire proprement
des requêtes SQL il n'y aurait aucun problème.
rhaa les clients ;)
les deux plus beau que j'ai vu c'est
- un requete générée recursivement de 3Mo (la requete). MySQL a fuit
(MySQL has gone away)
- une nouvelle impletation en java de la commande SQL count (a soivoir
un select * suivit d'un comptage en java)
rhaa .. ils sont du courage nos serveurs.
heureusement qu'ils n'ont pas de conscience, il ferait la grève sinon ;)
Snarf
--
"L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un
voulant le defier "
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
Si les clients savaient créer des indexes et faire proprement des requêtes SQL il n'y aurait aucun problème. rhaa les clients ;)
les deux plus beau que j'ai vu c'est - un requete générée recursivement de 3Mo (la requete). MySQL a fuit (MySQL has gone away)
- une nouvelle impletation en java de la commande SQL count (a soivoir un select * suivit d'un comptage en java)
rhaa .. ils sont du courage nos serveurs.
heureusement qu'ils n'ont pas de conscience, il ferait la grève sinon ;)
Snarf
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
Spyou
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.
mysql (show processlist);
tu parse la sortie, tu extrai la colonne Id et la colonne Time
et pour chaque ligne if ($time > 20) { mysql (kill $id); }
Et voila.
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 !).
Ou alors, si les prix pratiqués le permettent, aller se palucher le code du client pour comprendre comment ca marche et faire les actions correctrices idoines (parfois meme sans avoir des prix plus haut, le simple fait de faire ca permet d'economiser autant en hardware, temps de déploiement, etc ..)
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.
mysql (show processlist);
tu parse la sortie, tu extrai la colonne Id et la colonne Time
et pour chaque ligne
if ($time > 20) {
mysql (kill $id);
}
Et voila.
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 !).
Ou alors, si les prix pratiqués le permettent, aller se palucher le code
du client pour comprendre comment ca marche et faire les actions
correctrices idoines (parfois meme sans avoir des prix plus haut, le
simple fait de faire ca permet d'economiser autant en hardware, temps de
déploiement, etc ..)
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.
mysql (show processlist);
tu parse la sortie, tu extrai la colonne Id et la colonne Time
et pour chaque ligne if ($time > 20) { mysql (kill $id); }
Et voila.
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 !).
Ou alors, si les prix pratiqués le permettent, aller se palucher le code du client pour comprendre comment ca marche et faire les actions correctrices idoines (parfois meme sans avoir des prix plus haut, le simple fait de faire ca permet d'economiser autant en hardware, temps de déploiement, etc ..)
FightClub!
mysql (show processlist);
tu parse la sortie, tu extrai la colonne Id et la colonne Time
et pour chaque ligne if ($time > 20) { mysql (kill $id); }
Et voila.
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc. Pire encore sur des tables innodb il y a la plupart du temps un rollback, donc si on tue à 20, ça bouffe au moins 40 Bref, c'est une méthode applicable sur du mutualisé discount, mais c'est un peu trop bourrin par rapport à la qualité de service que j'estime devoir fournir.
Ou alors, si les prix pratiqués le permettent, aller se palucher le code du client pour comprendre comment ca marche et faire les actions correctrices idoines (parfois meme sans avoir des prix plus haut, le simple fait de faire ca permet d'economiser autant en hardware, temps de déploiement, etc ..)
Hé oui, c'est exactement ce qu'on fait... mais comme dis au début du post, c'est un peu le cauchemar de l'hébergeur ;)
mysql (show processlist);
tu parse la sortie, tu extrai la colonne Id et la colonne Time
et pour chaque ligne
if ($time > 20) {
mysql (kill $id);
}
Et voila.
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue
les requetes longues, mais pas forcément les requetes couteuses en
ressources. Par exemple ça tue aussi les connexions persistentes, et les
connexions bloquées par d'autres requetes, etc.
Pire encore sur des tables innodb il y a la plupart du temps un
rollback, donc si on tue à 20, ça bouffe au moins 40
Bref, c'est une méthode applicable sur du mutualisé discount, mais c'est
un peu trop bourrin par rapport à la qualité de service que j'estime
devoir fournir.
Ou alors, si les prix pratiqués le permettent, aller se palucher le code
du client pour comprendre comment ca marche et faire les actions
correctrices idoines (parfois meme sans avoir des prix plus haut, le
simple fait de faire ca permet d'economiser autant en hardware, temps de
déploiement, etc ..)
Hé oui, c'est exactement ce qu'on fait... mais comme dis au début du
post, c'est un peu le cauchemar de l'hébergeur ;)
tu parse la sortie, tu extrai la colonne Id et la colonne Time
et pour chaque ligne if ($time > 20) { mysql (kill $id); }
Et voila.
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc. Pire encore sur des tables innodb il y a la plupart du temps un rollback, donc si on tue à 20, ça bouffe au moins 40 Bref, c'est une méthode applicable sur du mutualisé discount, mais c'est un peu trop bourrin par rapport à la qualité de service que j'estime devoir fournir.
Ou alors, si les prix pratiqués le permettent, aller se palucher le code du client pour comprendre comment ca marche et faire les actions correctrices idoines (parfois meme sans avoir des prix plus haut, le simple fait de faire ca permet d'economiser autant en hardware, temps de déploiement, etc ..)
Hé oui, c'est exactement ce qu'on fait... mais comme dis au début du post, c'est un peu le cauchemar de l'hébergeur ;)
Spyou
mysql (show processlist);
tu parse la sortie, tu extrai la colonne Id et la colonne Time
et pour chaque ligne if ($time > 20) { mysql (kill $id); }
Et voila.
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas si elle est en sleep :)
Bref, c'est une méthode applicable sur du mutualisé discount, mais c'est un peu trop bourrin par rapport à la qualité de service que j'estime devoir fournir.
Si ce n'est pas du discount, il y'a moyen de surdimentionner assez pour pas avoir de probleme de charge :)
Hé oui, c'est exactement ce qu'on fait... mais comme dis au début du post, c'est un peu le cauchemar de l'hébergeur ;)
En meme temps, faut pas faire ce metier la si on est pas près a se faire enquiquinner par les clients a longueur de temps :p
mysql (show processlist);
tu parse la sortie, tu extrai la colonne Id et la colonne Time
et pour chaque ligne
if ($time > 20) {
mysql (kill $id);
}
Et voila.
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue
les requetes longues, mais pas forcément les requetes couteuses en
ressources. Par exemple ça tue aussi les connexions persistentes, et les
connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas
si elle est en sleep :)
Bref, c'est une méthode applicable sur du mutualisé discount, mais c'est
un peu trop bourrin par rapport à la qualité de service que j'estime
devoir fournir.
Si ce n'est pas du discount, il y'a moyen de surdimentionner assez pour
pas avoir de probleme de charge :)
Hé oui, c'est exactement ce qu'on fait... mais comme dis au début du
post, c'est un peu le cauchemar de l'hébergeur ;)
En meme temps, faut pas faire ce metier la si on est pas près a se faire
enquiquinner par les clients a longueur de temps :p
tu parse la sortie, tu extrai la colonne Id et la colonne Time
et pour chaque ligne if ($time > 20) { mysql (kill $id); }
Et voila.
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas si elle est en sleep :)
Bref, c'est une méthode applicable sur du mutualisé discount, mais c'est un peu trop bourrin par rapport à la qualité de service que j'estime devoir fournir.
Si ce n'est pas du discount, il y'a moyen de surdimentionner assez pour pas avoir de probleme de charge :)
Hé oui, c'est exactement ce qu'on fait... mais comme dis au début du post, c'est un peu le cauchemar de l'hébergeur ;)
En meme temps, faut pas faire ce metier la si on est pas près a se faire enquiquinner par les clients a longueur de temps :p
FightClub!
[SNIP]
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas si elle est en sleep :)
Tiens oui, pas bete ça. Jusqu'à présent j'utilisait les logs, je sens que je vais changer de méthode !
Bref, c'est une méthode applicable sur du mutualisé discount, mais c'est un peu trop bourrin par rapport à la qualité de service que j'estime devoir fournir.
Si ce n'est pas du discount, il y'a moyen de surdimentionner assez pour pas avoir de probleme de charge :)
En théorie oui.
Hé oui, c'est exactement ce qu'on fait... mais comme dis au début du post, c'est un peu le cauchemar de l'hébergeur ;)
En meme temps, faut pas faire ce metier la si on est pas près a se faire enquiquinner par les clients a longueur de temps :p
C'est sur.
[SNIP]
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca
tue les requetes longues, mais pas forcément les requetes couteuses en
ressources. Par exemple ça tue aussi les connexions persistentes, et
les connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas
si elle est en sleep :)
Tiens oui, pas bete ça. Jusqu'à présent j'utilisait les logs, je sens
que je vais changer de méthode !
Bref, c'est une méthode applicable sur du mutualisé discount, mais
c'est un peu trop bourrin par rapport à la qualité de service que
j'estime devoir fournir.
Si ce n'est pas du discount, il y'a moyen de surdimentionner assez pour
pas avoir de probleme de charge :)
En théorie oui.
Hé oui, c'est exactement ce qu'on fait... mais comme dis au début du
post, c'est un peu le cauchemar de l'hébergeur ;)
En meme temps, faut pas faire ce metier la si on est pas près a se faire
enquiquinner par les clients a longueur de temps :p
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas si elle est en sleep :)
Tiens oui, pas bete ça. Jusqu'à présent j'utilisait les logs, je sens que je vais changer de méthode !
Bref, c'est une méthode applicable sur du mutualisé discount, mais c'est un peu trop bourrin par rapport à la qualité de service que j'estime devoir fournir.
Si ce n'est pas du discount, il y'a moyen de surdimentionner assez pour pas avoir de probleme de charge :)
En théorie oui.
Hé oui, c'est exactement ce qu'on fait... mais comme dis au début du post, c'est un peu le cauchemar de l'hébergeur ;)
En meme temps, faut pas faire ce metier la si on est pas près a se faire enquiquinner par les clients a longueur de temps :p
C'est sur.
Dominique ROUSSEAU
Le mar, 04 avr 2006 at 22:46 GMT, Spyou a écrit :
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas si elle est en sleep :)
En sleep ou en calesson, hein, faut pas etre sectaire :)
Dom
Le mar, 04 avr 2006 at 22:46 GMT, Spyou <root@spyou.org> a écrit :
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca
tue les requetes longues, mais pas forcément les requetes couteuses
en ressources. Par exemple ça tue aussi les connexions persistentes,
et les connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas
si elle est en sleep :)
En sleep ou en calesson, hein, faut pas etre sectaire :)
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas si elle est en sleep :)
En sleep ou en calesson, hein, faut pas etre sectaire :)
Dom
FightClub!
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc. Suffit de regarder l'etat dans lequel est la requette .. on la tue pas
si elle est en sleep :)
En sleep ou en calesson, hein, faut pas etre sectaire :)
Profession : bruiteur sur newsgroup !
lol
Dom
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca
tue les requetes longues, mais pas forcément les requetes couteuses
en ressources. Par exemple ça tue aussi les connexions persistentes,
et les connexions bloquées par d'autres requetes, etc.
Suffit de regarder l'etat dans lequel est la requette .. on la tue pas
si elle est en sleep :)
En sleep ou en calesson, hein, faut pas etre sectaire :)
Oui oui, à partir des logs slow_query aussi c'est faisable. Mais ca tue les requetes longues, mais pas forcément les requetes couteuses en ressources. Par exemple ça tue aussi les connexions persistentes, et les connexions bloquées par d'autres requetes, etc. Suffit de regarder l'etat dans lequel est la requette .. on la tue pas
si elle est en sleep :)
En sleep ou en calesson, hein, faut pas etre sectaire :)
Profession : bruiteur sur newsgroup !
lol
Dom
atmaniak
FightClub! wrote:
Profession : bruiteur sur newsgroup !
lol
Je me demande du bruit ou du lol ce qui est le plus désagréable.
FightClub! wrote:
Profession : bruiteur sur newsgroup !
lol
Je me demande du bruit ou du lol ce qui est le plus désagréable.
