MySQL Tunning : Out of memory probleme ?

Bonjour à tous,

Je suis confrontée depuis une récente migration à un très gros problème.

Notre serveur de front était sur la même machine physique que notre serveur mysql. Or à cause d'une charge trop importante et de la sortie d'une nouvelle version de notre site, nous avons décidé de migrer notre front et ainsi de laisser notre serveur mysql seul sur la machine pour une pleine utilisation des ressources.

Et nous sommes maintenant confronté au problème suivant : Le site est très rapide au démarrage des deux serveurs, puis au bout d'une heure il commence a ralentir à chaque fois qu'il y a appel à mysql (que la page n'est pas déjà en cache) et enfin au bout de deux heures le serveur sql tombe avec ce message d'erreur :

#1135 - Can't create a new thread (errno 12); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug.


Notre my.cnf est configuré de la sorte:

Code:

---

1 2 3 4 5 6 7 8 9 10

key_buffer = 1000M max_allowed_packet = 32M thread_stack = 32M thread_cache_size = 400M sort_buffer_size = 700M myisam_sort_buffer_size = 700M read_rnd_buffer_size = 400M innodb_buffer_pool_size = 300M join_buffer_size = 300M tmp_table_size = 500M

---

Merci d'avance... Si je poste ici c'est que je suis désespérée.

La première chose à faire me semble être de regarder la mémoire consommée par le processus du serveur (bref ressortir "top", si c'est une machine linux), en particulier quand il commence à peiner. Les ralentissements pourraient indiquer que MySQL est "swappé", et éventuellement qu'il sature même le swap. Combien de RAM le serveur a-t-il ? Est-ce la version 64bits de MySQL ? Si c'est la version 32bits, le processus est limité quant à la mémoire qu'il peut utiliser (3Go sur linux, seulement 2 sur windows). Avec ce genre de configuration, il est possible que la limite des 2Go soit vite atteinte.

thread_cache_size est supposé être un nombre maximum de threads conservés en cache, donc je ne sais pas (en fait j'ai surtout peur) comment MySQL interprète "400M". Cela pourrait masquer une fuite de connexions ouvertes mais pas fermées. Que donnent des "SHOW PROCESSLIST" (ou bien les indicateurs sur les connexions de MySQL Administrator) ?

La valeur de thread_stack me semble énorme : Le défaut est en dessous de 200Ko ! Croisé avec thread_cache_size, cela pourrait monopoliser énormément de mémoire et expliquer le message d'erreur.

Bonne chance.

Le top est clean.. Jamais au dessus de 30%.
Je suis sous une architecture 32 bits et lorsque mon front était sur la meme machine physique que la BDD et que mes requetes n'étaient pas optimisées, on montait parfois a 70% de mem mais ca n'a jamais crashé :/

Je vais check tout ce que tu avances. En tout cas merci pour ces éléments de réponses.

Comme le dit Sivrît, certains de tes paramètres sont très étranges (à revoir ultérieurement...)

Pour ton problème, s'il ne s'agit pas d'un problème de mémoire, c'est qu'il y a quelque part une limitation du nombre de threads/fichiers ouverts.

Ca n'a pas l'air d'être le max_connections qui est trop faible (à vérifier peut-être quand même), l'erreur est alors normalement 'too many connections'.
Tu peux regarder la variable open_files_limit, qui t'indique le nombre de descripteurs de fichiers max disponibles pour mysqld, mais il y a peut-être plus de chance pour que ce soit ton OS qui te limite. Par exemple, il me semble que sous Linux, un utilisateur non root n'a le droit d'avoir que 1024 descripteurs de fichiers.

Stéphane

C'était bien ça.

Merci beaucoup.

Problème résolu ;)