Salut,

je ne suis pas sur que ce post soit dans le bon forum mais je savais pas ou le mettre...
voila j ai installé la version de mysql 4.024 sur FC3 tout fonctionne a merveille mais par contre lors d un load très important (en faisant un stress testing avec ab : apache benchmark, ou openSTA) il y a de nombreuses requètes qui plantent, voici un passage du httpd/error_log :

[client 83.194.106.81] PHP Warning: mysql_connect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (11) in /var/www/html/scripts/library/init_var.php on line 28
[client 83.194.106.81] PHP Warning: mysql_select_db(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (11) in /var/www/html/scripts/library/init_var.php on line 29
[client 83.194.106.81] PHP Warning: mysql_select_db(): A link to the server could not be established in /var/www/html/scripts/library/init_var.php on line 29

je ne sais pas exactement d ou ça vient je fait des tests avec 200 concurent users et je pensais que ça allait passer sans trop de problème.
Avec SElinux activé pour mysqld j avais les meme problèmes sauf que le message d erreur parlait en plus de setrlimit(24).

Si quelqu un pouvait m éclairer a ce sujet ce serait sympa.
Mon impression pour l instant c est que le test essaye d accéder trop de fois simultanöment au fichier sock de mysql si bien qu il est bloqué par le systeme (par ulimit peut etre) j ai donc augmenté dans ulimit le nombre de fichier max de 1024 a 8192 juste pour voir mais ça ne change rien 🙁

J espère que j ai réussi a bien expliqué mon problème sinon hésitez pas a demander plus de détails 😉

A +
7 jours plus tard
Salut 🙂

il y a toujours personne pour me donner un petit coup de pouce sur ce problème la ?

Je peux donner plus de détails si besoin, c est un soucis ennuyeux et ma configuration mysql / php /apache semble etre correcte donc le problème pourrait bien venir de Fedora quelque chose qui empecherais des accès simultanné trop nombreux au socket mysql... MAis quoi???

J ai essayé avec et sans SElinux sans différence. Je suis perdu la :-? ... Help...
questions pour la forme !:-o

utilises-tu le support transactionnel de mysql (innodb) ?

C'est quoi la configuration de ta machine ?
  • [supprimé]

Salut,

Oui je suis en innodb, et voici la config de la machine (pas surpuissante) :
512 Mo de memoire
2.66 Cpu
Pour info le serveur apache tourne dessus aussi, mais bon malgrès tout cela devrait suffir et le problème de connection peut apparaitre alors qu il y a encore 226 Mo de mémoire dispo...

Tu penses que innoDB pourrais y etre pour quelque chose ?

Sinon tu as ue piste car c est un problème courrant, on peut voir ce message sur pas mal de site en php / mysql quand le load est trop important mais j ai pas trouvé d aide jusqu a présent mem sur le site de mysql.

En faisant une recherche google avec le message d erreur mysql.sock tu verras qu il y a de nombreuse réponses qui en fait correspondent a des sites qui ont eu le meme problème que le mien...
lorsque le message contient mysql.sock (2) ou mysq.sock (111) il s agit d un autre problème (mysql.sock avec de mauvais droit ou mysql non démarré...) seul mysql.sock (11) correspond a mon problème, pour tester je vais esayer de faire un stress testing sur un script utilisant myisam pour voir si ça a une influence...

Merci de te pencher sur mon cas ! :-D

A +
Bon et bien j ai fait un test et apparement en myIsam le meme problème apparait. Pourtant la page de test que j utilise ne contient qu une toute petite requète, le problème semble donc venir de la gestion des processus, thread de mysql, si il y a trop de connections simultanés les processus ne sont pas libéré proprement (zombie) et l accès au socket devient instable d ou le message d erreur, par contre je ne sais pas quoi faire pour l'éviter...

Comme le problème est présent sur la version 3.23 de yum mais aussi avec les rpms officiel de mysql 4.0.24. J en conclu que le problème doit etre présent sur toutes les versions entre ces deux la aussi.

Est ce que l un d entre vous pourrait faire un test pour voir si le meme problème apparait ? ce serait vraiment l idéal pour etre sur que le problème viens de ma config ou non ...

Pour reproduire le problème il vous faut un serveru apache et mysql (version de fedora 3.23.x ou version venant des rpm officiel de mysql).
Ensuite il faut faire un petit stress testing sur une page php contenant quelques requètes mysql (pas forcément de grosse requètes, moi avec une seule requète assez simple ça suffit). La commande pour lancer le test se fait a l aide de ab (apache benchmark) : ab -c100 -n5000 "http://localhost/page.php"
5c est en fait un test avec 100 utilisateurs simultanés qui vont visiter la page 5000 fois...
En meme temps il vous faut ouvrir le fichier de log de apache tail -f /var/log/httpd/error_log et vous devriez voir si les memes messages d erreurs que pour moi apparaissent.
A la fin du test de ab le résultat affichera combien de requète ont réussie et combien on échoué. (ab consière les pges qui n ont des tailes différents comme des erreures par concéquent si le contenu de la page de test contient la date et heure du jours on un tesxt qui change a chaque fois il considerera la requète comme échoué, ce qui comptera alors c est le fichier de log ! )


Merci d avance de me donner des idées pour résoudre le problème et aussi de faire le petit test sur une de vos machine si possible (attention cela va utiliser pas mal de CPU et de mémoire donc pendant une ou deux minutes le pc sera plus trop accessible...)

A + 🙂
Je viens de faire les tests chez moi.

Client (exécutant la commande ab):
. FC3
. Bi-Xeon 2.8 Ghz (4 processeurs. logiques).
. Carte réseau Gigabit.

Serveur (exécutant LAMP)
. FC3
. Pentium IV 3.0 Ghz
. Carte réseau 100 Mb
. Apache httpd-2.0.52-3.1
. Php 5.0.4-8.remi
. MySQL 4.1.11-2 (fedora)
Concurrency Level: 200
Time taken for tests: 10.562295 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 5480000 bytes
HTML transferred: 3550000 bytes
Requests per second: 946.76 [#/sec] (mean)
Time per request: 211.246 [ms] (mean)
Time per request: 1.056 [ms] (mean, across all concurrent requests)
Transfer rate: 506.61 [Kbytes/sec] received
Et j'ai pu reproduire ton problème.
Failed requests: 17
Explication : avec une base de données, ce qui coute le plus "cher", c'est la connexion (vrai avec tous les SGBD)

Il suffit donc d'utiliser les connexions permanentes pour résoudre ton problème, c'est dire utiliser mysql_pconnect à la place de mysql_connect.

A+
Ok merci pour ta réponse 🙂
c est bien ce qui me semblait le problème n est pas seulement présent pour moi...
As tu vu si le message d erreur était le meme pour toi (concernant mysql.sock) ?

Sinon y a t il d autres avantages inconveniant pour l utilisation des connections perssistantes? En principe j ai remarqué que les connections "standard" sont utilisées (mysql_connect) il y a peut etre une raison concernant les performance ?

Et dernière petite question n y a t il pas d option pour que les connections ne plantent pas lorsqu'il y a une demande trop importante? par exemple une file d attente, ou une augmentation du nombre de processus supportté par le système... J ai déja essayé de changer les paramètre ulimit , pour les file descriptors par exemple mais aussi pour le nombre de processus max supporté par utilisateurs, mais ça change rien.

En tou tcas merci beaucoup d avoir fait le test, au moins je sais que je ne suis pas le seul, c est très étrange quand meme qu il n y est aucune information officielle sur ce problème et aucun indice pour le résoudre...

A +
ajji a écrit:
As tu vu si le message d erreur était le meme pour toi (concernant mysql.sock) ?
Oui.
Sinon y a t il d autres avantages inconveniant pour l utilisation des connections perssistantes? En principe j ai remarqué que les connections "standard" sont utilisées (mysql_connect) il y a peut etre une raison concernant les performance ?
Cela dépend de ton application.

Une application qui utilise toujours le même utilisateur (login/mdp dans le fichier de config.) sur un serveur dédié sera beaucoup plus performante avec une connexion permanente. J'utilise habituellement ce type de config sur des applications intranet.

Par contre dans le cas d'un environnement serveur partagé par un nombre important d'utilisateurs, tu risque de dépasser les capacités (nombre maximum de connexions) du serveur MySQL. Par exemple dans le cas d'une application d'enregistrement d'informations utilisant l'authentification http/MySQL (chaque utilisateur dispose d'un compte) j'utilise les connexions classiques.

Cela me permet d'optimiser le serveur MySQL en limitant les connexions (100 par défaut).

Cela dépend aussi du mode de configuration d'apache en prefork (process) ou worker (thread) car il faut multiplier le nombre de connexions permanentes par le nombre de process httpd actifs.
Et dernière petite question n y a t il pas d option pour que les connections ne plantent pas lorsqu'il y a une demande trop importante? par exemple une file d attente, ou une augmentation du nombre de processus supportté par le système... J ai déja essayé de changer les paramètre ulimit , pour les file descriptors par exemple mais aussi pour le nombre de processus max supporté par utilisateurs, mais ça change rien.
Je ne sais pas trop, consulte le fichier my.conf. La distribution MySQL (sources) contient plusieurs exemples en fonction de la taille du serveur.

Mais il faut aussi être raisonnable. Le test de stress exécute près de 1000 requêtes par seconde (avec un taux d'erreur trés faible <0,2%). Tu n'es pas près, je pense, d'avoir cela sur un serveur (je suis déjà fier d'en avoir 1000 à l'heure).

A+
Ok merci beaucoup pour ta réponse... :-D

l utilisation de php /mysql sur mon serveur va rester assez simple, et je ne pense pas avoir de nombreuses connections simultanées pour mon site et perso et le forum qui va avec...

Par contre j envisage d utiliser php/mysql a mon travail, je travail a la conceptions et maintenances des sites internets de ma compagnie (une grosse grosse boite), et j ai la chance d etre le chef de projet pour la migration de notre logiciel actuel vers une autre solution... Comme c est pour un usage public; l intranet lui tourne sur d autre serveurs / logiciels (SAP portal); je pensais migrer vers mysql php, or les sites internet sont en fait un parc de 50 sites (un par compagnies dans le monde) avec une partie pour le content management , le load risque d etre élevé et meme si nos servers devraient supporter le choc je voulais etre sur de ne pas me retrouver avec un message mysql.sock une fois en prod :-?

L utilisation des mysql_pconnect pourrait etre problèmatique, si la connection a un problème alors qu il y a lock sur une table cela va bloquer la table, pas terrible pour la gestion de contenu.
Et ce serait pour une utilisation en innodb ce qui la encore risque de poser problème avec les connections perssistante.

Donc me voila un peu bloqué... En tout cas merci pour tes conseils et infos, si tu as d autres pistes a me donner ce serait vraiment bienvenue !

Le problème de connection semblent en tout cas etre moins grave sur ton server, que sur le mien quand j ai le problème avec les thread cela peut vite aller jusqu'a la moitié des requètes qui échouent...
Pourtant j utilise uen requète toute simple, La puissance du serveur permet peu etre de résoudre le problème ou a la limite d augmenter la limite a ne pas dépasser avant erreure ?

Sinon c est peut etre le fait de relancer le test presque tout de suite après un test précédent qui déclenche le problème ou la moitié des connections échouent, comme si les connections précédentes étaient responsable du disfonctionnement des nouvelles...

pour l utilistation de apache en worker il me semblait que ce n etait pas compatible avec PHP ? confirmation ?

Merci encore et si quelqu un d autre a des idées ou une autre piste a étudier faut pas hésiter 🙂

A +
j'avais un problème de ce type avec des requêtes trop longues à exécuter, j'ai modifié une variable de timeout dans /etc/php.ini.

Vu ton environnment, as-tu envisagé POSTGRESQL qui a la réputation d'être beaucoup plus résistant à la montée en charge que mysql ?
Salut,

je ne pense pas que le problème soit lié à des requètes trop longues à éxecuter, et si c était le cas mysql devrait très bien pouvoir les gérer quand meme...

Pour faire le test j ai mis en place une petite page avec juste un requète sql (pas bien grosse) donc le problème vient d autre chose.

Ce qui est important, c est le message d erreur : Can't connect to localMySQL server through socket '/var/lib/mysql/mysql.sock' (11)

le 11 veut dire : Ressource Temporary Unavailable , ce qui me fait penser que c est la gestion des sockets qui est la cause de tout le problème.
Remi a confirmé que la création d une nouvelle connection en passant par une socket était une opération un peu lourde. Donc si de trop nombreuses demandes sont faites en meme temps le systeme n arrive peut etre plus a le gérer...

En attendant pour tester j ai essayé de ne plus passer par les socket Unix mais par socket tcp ( c est a dire me connecter en entrant l adresse IP et non pas localhost). Et comme par magie il n y a plus d erreures toutes les requètes meme 50 000 avec 250 utilsateurs simultanés passent sans problème!!!

La conclusion serait donc que les socket Unix et donc l utilisation de mysql.sock ne supporte pas de nombreuses connections simultanées au moins sur mon systeme (petit serveur avec peu de mémoire) et aussi sur celui de remi dans de moindres mesure.

Mais il parait aussi que le fait de passer par tcp et non les socket Unix est un peu moins performant, y a t il d autres avantages inconvéniant pour l utilisation de l un plus que l autre?
Actuellement la majorité des webhosters passent par des socket Unix (la connection avec mysql_connect se fait avec localhost), mais bon il est pas rare de voir la meme erreur sur les sites qu ils hébergent!!!

Je pense que les gros sites utilisant mysql passent de toute manière par tcp etant donné que le serveur web et le serveur mysql ne doivent pas se trouver sur la meme machine...

J attends de voir si vous avez des conseils sur l utilisation de tcp et aussi si vous ne trouvez pas une explication pour ce problème de socket.

A + 🙂
Salut,


Juste une petite relance pour savoir si quelqu'un en savait plus sur le fait d utiliser les sockets TCP plutot que les socket Unix.
Et sinon je suis toujours perplexe par rapport aux sockets Unix de mysql qui lors d une charge importante sur le server ne sont pas toujours accessible... Il bien y avoir un paramaitre quelque part dans fedora pour autoriser un nombre important de thread/socket d etre connecté en meme temps ?

A + 🙂
  • [supprimé]

Salut, j'ai le même problème sur mon serveur

Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (11)

C'est un serveur OVH, un p4++
RedHat 7.2 OVH
P4 3,2 Ghz HT
2Go de Ram
Il héberge un gros site et l'erreur apparait quand il y a du monde dessus.

Je vais me renseigner pour se connecter en TCP, ça peut être une solution.
Petite remarque : lorsque j'ai effectué mes tests de charge, c'était entre deux machines différentes, donc via une connexion TCP. Et le problème s'est aussi produit.

Il est simplement moins fréquent dans ce cas.

A+