empecher mysq de planter

11 réponses

Auteur	Message
abravanel666 \| Modérateur Inscrit le : 19/07/2009	# Le 17/02/2010 à 10:47 Hello Il m'est arrivé un truc con cette nuit, je lance une requête sql sous phpmyadmin complètement bidon (un select user from table where not in (select user from table2 where 1)) sur des tables gigantesques de plusieurs millions d'entrées. Bref ca mouline, je laisse un peu tourner et mon mysql devient complet à l'arrache, je me paye des tables corrompues etc ... l'a fallut tout restaurer !! Jtrouve incroyable qu'une requête select puisse planter complet un serveur mysql. Est ce que y a des règlages pour empécher ce genre de chose ? http://www.magasins-usine.info http://www.shoppingactu.com
abravanel666 \| Sylvain Modérateur Inscrit le : 19/07/2009	# Le 17/02/2010 à 12:22 tu fais comment pour limiter la mémoire, j'avais fait mes calculs en tunant le maxconnection * le nombre de buffers m'enfin c'est pas très précis jpeux avoir un exemple de my.cnf tuné par exemple pour un mysql mutualisé ? (Message édité le 17-02-2010 à 12h37 par abravanel666) http://www.magasins-usine.info http://www.shoppingactu.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 17/02/2010 à 13:37 éventuellement y a mysqltuner qui te fait le calcul... mais c'est le max théorique qu'il te sort, dans le cas où toutes les connexions remplissent tous les buffers simultanément. daevel : infogérance et conseil \|\| moi
tty2 \| Serge Modérateur Inscrit le : 10/05/2005	# Le 17/02/2010 à 16:48 il m'est arrivé un truc con dernierement meme si ça n'a rien à voir... de base chez ovh la partition mysql fait 3 Go, et du coup elle etait pleine et mysql deconnait tout le temps, c'est completement con sachant que l'espace disque est de 2 fois 750 Go
abravanel666 \| Sylvain Modérateur Inscrit le : 19/07/2009	# Le 17/02/2010 à 16:53 Bool a dit : éventuellement y a mysqltuner qui te fait le calcul... mais c'est le max théorique qu'il te sort, dans le cas où toutes les connexions remplissent tous les buffers simultanément. Oui c'est comme ca que j'ai ajusté mes buffers m'enfin c'est pas terrible. Comment qu'ils font pour configurer les mysql sur des mutualisé ? http://www.magasins-usine.info http://www.shoppingactu.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 17/02/2010 à 16:57 Sur du mutu tu es généralement bien plus strict, du genre tu fixes à 5 connexions simultannées maxi par compte. Et je pense que tu es près à sacrifier un peu de perf (en étant plus strict sur les buffers justement), quitte à ce que ce soit plus stable. daevel : infogérance et conseil \|\| moi
abravanel666 \| Sylvain Modérateur Inscrit le : 19/07/2009	# Le 17/02/2010 à 17:00 Bool a dit : Sur du mutu tu es généralement bien plus strict, du genre tu fixes à 5 connexions simultannées maxi par compte. Y a un truc que je pige pas c'est comment 1 seule requete peut faire tout planter. Jsuis pas sur que limiter à 5-10 connexions règle le pb. J'ai pas trouvé de max_execution time au niveau de mysql histoire qu'il lasse tomber les requêtes qui prennent plus de 60 secondes. y a des trucs possibles dans php.ini m'enfin j'aurais préféré gérer ca direct au niveau BDD. http://www.magasins-usine.info http://www.shoppingactu.com
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 17/02/2010 à 17:07 Avec une tres grosse requete tu peux saturer la memoire si tes buffer ne sont pas limites, ca va swapper, et si tu arrives au bout du swap, ton serveur va planter
ultrajoe \| Jérôme Membre Inscrit le : 16/07/2008	# Le 17/02/2010 à 17:28 abravanel666 a dit : J'ai pas trouvé de max_execution time au niveau de mysql histoire qu'il lasse tomber les requêtes qui prennent plus de 60 secondes. y a des trucs possibles dans php.ini m'enfin j'aurais préféré gérer ca direct au niveau BDD. wait-timeoout et/ou interactive-timeout (pour les connections persistantes) devrait répondre à ton besoin non ?
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 17/02/2010 à 18:08 Déjà faudrait savoir si c'est à cause d'une saturation mémoire ou non que ton MySQL a sauté. T'as pas de log ou de monitoring qui puissent répondre à ça ? Si c'est une saturation mémoire, généralement t'as le OOM Killer qui est super bavard dans les logs (kern.log par exemple) ; si c'est autre chose ce sera dans le log normal de MySQL (syslog sous Debian). Ca ressemble à ça : Feb 17 16:20:22 press4 kernel: [457719.976104] mysqld invoked oom-killer: gfp_mask=0x200da, order=0, oomkilladj=0 (roh le boulet qui a configuré ce serveur ) daevel : infogérance et conseil \|\| moi
abravanel666 \| Sylvain Modérateur Inscrit le : 19/07/2009	# Le 17/02/2010 à 18:17 rien dans le kern.log ou le syslog.log a part quand j'ai fait un restart de mysqld ce matin et ou il me trouve plein de tables corrompues http://www.magasins-usine.info http://www.shoppingactu.com
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 17/02/2010 à 19:02 Donc c'est pas une saturation, à moins que tu ais toi même coupé MySQL à la hache ? (à coup de kill -9) daevel : infogérance et conseil \|\| moi

Auteur

Message

Inscrit le : 19/07/2009

# Le 17/02/2010 à 10:47

Hello

Il m'est arrivé un truc con cette nuit, je lance une requête sql sous phpmyadmin complètement bidon (un select user from table where not in (select user from table2 where 1)) sur des tables gigantesques de plusieurs millions d'entrées. Bref ca mouline, je laisse un peu tourner et mon mysql devient complet à l'arrache, je me paye des tables corrompues etc ... l'a fallut tout restaurer !!
Jtrouve incroyable qu'une requête select puisse planter complet un serveur mysql.
Est ce que y a des règlages pour empécher ce genre de chose ?

http://www.magasins-usine.info http://www.shoppingactu.com

abravanel666 | Sylvain
Modérateur

Inscrit le : 19/07/2009

# Le 17/02/2010 à 12:22

tu fais comment pour limiter la mémoire, j'avais fait mes calculs en tunant le maxconnection * le nombre de buffers m'enfin c'est pas très précis
jpeux avoir un exemple de my.cnf tuné par exemple pour un mysql mutualisé ?

(Message édité le 17-02-2010 à 12h37 par abravanel666)

http://www.magasins-usine.info http://www.shoppingactu.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 17/02/2010 à 13:37

éventuellement y a mysqltuner qui te fait le calcul... mais c'est le max théorique qu'il te sort, dans le cas où toutes les connexions remplissent tous les buffers simultanément.

daevel : infogérance et conseil || moi

tty2 | Serge
Modérateur

Inscrit le : 10/05/2005

# Le 17/02/2010 à 16:48

il m'est arrivé un truc con dernierement meme si ça n'a rien à voir...
de base chez ovh la partition mysql fait 3 Go, et du coup elle etait pleine et mysql deconnait tout le temps, c'est completement con sachant que l'espace disque est de 2 fois 750 Go

abravanel666 | Sylvain
Modérateur

Inscrit le : 19/07/2009

# Le 17/02/2010 à 16:53

Bool a dit :
éventuellement y a mysqltuner qui te fait le calcul... mais c'est le max théorique qu'il te sort, dans le cas où toutes les connexions remplissent tous les buffers simultanément.

Oui c'est comme ca que j'ai ajusté mes buffers m'enfin c'est pas terrible. Comment qu'ils font pour configurer les mysql sur des mutualisé ?

http://www.magasins-usine.info http://www.shoppingactu.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 17/02/2010 à 16:57

Sur du mutu tu es généralement bien plus strict, du genre tu fixes à 5 connexions simultannées maxi par compte. Et je pense que tu es près à sacrifier un peu de perf (en étant plus strict sur les buffers justement), quitte à ce que ce soit plus stable.

daevel : infogérance et conseil || moi

abravanel666 | Sylvain
Modérateur

Inscrit le : 19/07/2009

# Le 17/02/2010 à 17:00

Bool a dit :
Sur du mutu tu es généralement bien plus strict, du genre tu fixes à 5 connexions simultannées maxi par compte.

Y a un truc que je pige pas c'est comment 1 seule requete peut faire tout planter. Jsuis pas sur que limiter à 5-10 connexions règle le pb.
J'ai pas trouvé de max_execution time au niveau de mysql histoire qu'il lasse tomber les requêtes qui prennent plus de 60 secondes. y a des trucs possibles dans php.ini m'enfin j'aurais préféré gérer ca direct au niveau BDD.

http://www.magasins-usine.info http://www.shoppingactu.com

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 17/02/2010 à 17:07

Avec une tres grosse requete tu peux saturer la memoire si tes buffer ne sont pas limites, ca va swapper, et si tu arrives au bout du swap, ton serveur va planter

ultrajoe | Jérôme
Membre

Inscrit le : 16/07/2008

# Le 17/02/2010 à 17:28

abravanel666 a dit :
J'ai pas trouvé de max_execution time au niveau de mysql histoire qu'il lasse tomber les requêtes qui prennent plus de 60 secondes. y a des trucs possibles dans php.ini m'enfin j'aurais préféré gérer ca direct au niveau BDD.

wait-timeoout et/ou interactive-timeout (pour les connections persistantes) devrait répondre à ton besoin non ?

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 17/02/2010 à 18:08

Déjà faudrait savoir si c'est à cause d'une saturation mémoire ou non que ton MySQL a sauté. T'as pas de log ou de monitoring qui puissent répondre à ça ?
Si c'est une saturation mémoire, généralement t'as le OOM Killer qui est super bavard dans les logs (kern.log par exemple) ; si c'est autre chose ce sera dans le log normal de MySQL (syslog sous Debian). Ca ressemble à ça :

Feb 17 16:20:22 press4 kernel: [457719.976104] mysqld invoked oom-killer: gfp_mask=0x200da, order=0, oomkilladj=0

(roh le boulet qui a configuré ce serveur

)

daevel : infogérance et conseil || moi

abravanel666 | Sylvain
Modérateur

Inscrit le : 19/07/2009

# Le 17/02/2010 à 18:17

rien dans le kern.log ou le syslog.log
a part quand j'ai fait un restart de mysqld ce matin et ou il me trouve plein de tables corrompues

http://www.magasins-usine.info http://www.shoppingactu.com

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 17/02/2010 à 19:02

Donc c'est pas une saturation, à moins que tu ais toi même coupé MySQL à la hache ? (à coup de kill -9)

daevel : infogérance et conseil || moi

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.