fulltext / crash de la table

9 réponses

Auteur	Message
krucial \| Administrateur Inscrit le : 09/03/2005	# Le 27/04/2008 à 18:31 Salut J'ai un petit probleme sur Vacanceo.com. J'ai indexé des champs de tables en fulltext. Depuis, regulierement, les tables crashes (table nanana has crashed). Ca le fait tout le temps, avec toutes les tables. J'ai chié quelque part ? Je ne comprends pas là. JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 27/04/2008 à 18:49 Salut, Jamais eu de pb de ce type sur du fulltext Quelle volumétrie ? Quelle utilisation ? Vérifie que tu as bien configuré mysql pour que l'espace ram alloué au total des index soit suffisant (param key_buffer_size de memoire) Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 27/04/2008 à 19:12 Passe là en innodb ;) Elle doit souvent être LOCKé et tu dois faire des UPDATE / INSERT en quantité. @+ Jean-Philippe
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 27/04/2008 à 19:36 Hello, Normalement une table "crashed", ça ne se produit que si quelque chose empêche la mise à jour des indexes : coupure électrique, plantage de la machine, ou encore disque plein. Tu rencontres souvent des problèmes de ce genre ? daevel : infogérance et conseil \|\| moi
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 27/04/2008 à 19:43 Pas de coupure, pas de plantage, espace disque ok. Pas d'erreur disque dans les logs. A priori, ca serait un probleme d'ecriture ? Je n'ai jamais eu ce genre de probleme avant. Dev : tu peux m'en dire plus ? Les index sont en ram ? JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 27/04/2008 à 20:36 Idéalement il y a une copie de tous les indexes en mémoire oui ; à condition justement que le key_buffer_size corresponde. En tous cas avoir des problèmes de corruption sans crash ni autre coupure, c'est un énorme bug pour moi. daevel : infogérance et conseil \|\| moi
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 27/04/2008 à 20:53 Bool > non cela n'est pas un bug, loin de là ; c'est juste une très mauvaise configuration. Il y a 15 jours un consultant Mysql est venu chez nous pour corriger ce genre de problème. Résultat : - Il a passer les tables avec beaucoup d'écritures en innodb - Notre key_buffer_size n'était pas fonctionnelle car on avait mysql en 32 bits et la valeur qu'on lui avait mis était hors de portée. => on est passé sur une debian 64 bits avec mysql en 64 bits et on a pu mettre 1go de key_buffer_size - Il a réservé 5 go en mémoire vive pour innodb Et cela marche nickel maintenant @+ Jean-Philippe
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 27/04/2008 à 21:01 Moi ça me choque Qu'il y ait des perfs pourries car c'est mal configuré, ça me semble normal. Mais qu'il y ait une corruption de données, pour un SGBD c'est n'importe quoi. En passant : 1Go de key_buffer_size, c'est "hors de portée" pour du 32bits ou bien vous y aviez collé plus de 4Go ? daevel : infogérance et conseil \|\| moi
flush \| Jean-Philippe Modérateur Inscrit le : 09/05/2005	# Le 27/04/2008 à 22:05 Bool > En MyIsam, avec beaucoup d'écritures ... apparement c'est plutôt courant. D'ailleur à noté que REPAIR TABLE c'est pas forcément LA solution, il faut mieux supprimer les clés et les refaire, et après faire un repair table. C'était hors de portée, le maximum était de 512 Mo assez bizzarement ... On avait mis 1GO dans le my.cnf, mais dans show variables, on était à la valeur par défaut ... Enfaite en 32 bits, c'est tout mysqld qui ne peux pas dépasser 4go en mémoire. @+ Jean-Philippe
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 27/04/2008 à 23:35 Je suis entierement d'accord que meme en utilisation intensive mais correcte, une corruption des tables serait un bug. A mon avis, ca venait d'un probleme de fond sur le serveur, le fait de le passer sur une nouvelle machine a du resoudre le probleme. On avait eu ca un temps aussi, un serveur qui n'arrivait pas a tenir la charge, il crashait a chaque fois. On a changé la machine, et tout etait résolu avec exactement le meme schema et les memes donnees. A noter que le REPAIR TABLE "de base" ne repare pas a 100%, mais fait une réparation rapide et peut donc ne pas résoudre un problème de fond : http://dev.mysql.com/doc/refman/5.0/fr/repair-tabl...

Auteur

Message

krucial |
Administrateur

Inscrit le : 09/03/2005

# Le 27/04/2008 à 18:31

Salut

J'ai un petit probleme sur Vacanceo.com. J'ai indexé des champs de tables en fulltext. Depuis, regulierement, les tables crashes (table nanana has crashed). Ca le fait tout le temps, avec toutes les tables.

J'ai chié quelque part ? Je ne comprends pas là.

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 27/04/2008 à 18:49

Salut,

Jamais eu de pb de ce type sur du fulltext
Quelle volumétrie ? Quelle utilisation ?

Vérifie que tu as bien configuré mysql pour que l'espace ram alloué au total des index soit suffisant (param key_buffer_size de memoire)

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 27/04/2008 à 19:12

Passe là en innodb ;)

Elle doit souvent être LOCKé et tu dois faire des UPDATE / INSERT en quantité.

@+ Jean-Philippe

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 27/04/2008 à 19:36

Hello,

Normalement une table "crashed", ça ne se produit que si quelque chose empêche la mise à jour des indexes : coupure électrique, plantage de la machine, ou encore disque plein.
Tu rencontres souvent des problèmes de ce genre ?

daevel : infogérance et conseil || moi

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 27/04/2008 à 19:43

Pas de coupure, pas de plantage, espace disque ok. Pas d'erreur disque dans les logs. A priori, ca serait un probleme d'ecriture ?

Je n'ai jamais eu ce genre de probleme avant.

Dev : tu peux m'en dire plus ? Les index sont en ram ?

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 27/04/2008 à 20:36

Idéalement il y a une copie de tous les indexes en mémoire oui ; à condition justement que le key_buffer_size corresponde.

En tous cas avoir des problèmes de corruption sans crash ni autre coupure, c'est un énorme bug pour moi.

daevel : infogérance et conseil || moi

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 27/04/2008 à 20:53

Bool > non cela n'est pas un bug, loin de là ; c'est juste une très mauvaise configuration. Il y a 15 jours un consultant Mysql est venu chez nous pour corriger ce genre de problème.

Résultat :
- Il a passer les tables avec beaucoup d'écritures en innodb
- Notre key_buffer_size n'était pas fonctionnelle car on avait mysql en 32 bits et la valeur qu'on lui avait mis était hors de portée. => on est passé sur une debian 64 bits avec mysql en 64 bits et on a pu mettre 1go de key_buffer_size
- Il a réservé 5 go en mémoire vive pour innodb

Et cela marche nickel maintenant

@+ Jean-Philippe

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 27/04/2008 à 21:01

Moi ça me choque Qu'il y ait des perfs pourries car c'est mal configuré, ça me semble normal. Mais qu'il y ait une corruption de données, pour un SGBD c'est n'importe quoi.

En passant : 1Go de key_buffer_size, c'est "hors de portée" pour du 32bits ou bien vous y aviez collé plus de 4Go ?

daevel : infogérance et conseil || moi

flush | Jean-Philippe
Modérateur

Inscrit le : 09/05/2005

# Le 27/04/2008 à 22:05

Bool > En MyIsam, avec beaucoup d'écritures ... apparement c'est plutôt courant. D'ailleur à noté que REPAIR TABLE c'est pas forcément LA solution, il faut mieux supprimer les clés et les refaire, et après faire un repair table.

C'était hors de portée, le maximum était de 512 Mo assez bizzarement ...

On avait mis 1GO dans le my.cnf, mais dans show variables, on était à la valeur par défaut ...

Enfaite en 32 bits, c'est tout mysqld qui ne peux pas dépasser 4go en mémoire.

@+ Jean-Philippe

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 27/04/2008 à 23:35

Je suis entierement d'accord que meme en utilisation intensive mais correcte, une corruption des tables serait un bug.

A mon avis, ca venait d'un probleme de fond sur le serveur, le fait de le passer sur une nouvelle machine a du resoudre le probleme.

On avait eu ca un temps aussi, un serveur qui n'arrivait pas a tenir la charge, il crashait a chaque fois. On a changé la machine, et tout etait résolu avec exactement le meme schema et les memes donnees.

A noter que le REPAIR TABLE "de base" ne repare pas a 100%, mais fait une réparation rapide et peut donc ne pas résoudre un problème de fond : http://dev.mysql.com/doc/refman/5.0/fr/repair-tabl...

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.