Forum Linux.général MySQL : identifier les sources des Tentatives échouées / Arrêts prématurés

• # Ah et j'oubliais...

  Posté par Henry-Nicolas Tourneur (site web personnel) le 22 janvier 2009 à 11:07. Évalué à 1.

  

  Je doute que la faute soit au code en PHP, car en PHP il y a :
  - Essentiellement des logiciels connus que j'utilise (egroupware, phpmyadmin, drupal, un soft de mailing list à la con)
  - Un site web qui ne pose pas de problème (code bien inspecté).
  - Un "wrapper" qui sert à faire le lien entre postfix et maildrop, code lu et relu et rerelu, marche niquel.
  
  Donc le problème vient soit de courier soit de railo, j'ai un petit penchant pour Railo mais bon... c'est pas très objectif.

  • [^] # Re: Ah et j'oubliais...

    Posté par Loïc d'Anterroches (site web personnel) le 22 janvier 2009 à 11:24. Évalué à 1.

    

    Je me pose la question de savoir si cela ne pourrait pas venir quand même de PHP, souvent en PHP on ouvre une connexion et on la laisse mourir en fin d'exécution du script, PHP ferme automatiquement la connexion en fin d'exécution. La fermeture brutale par PHP pourrait être interprétée par MySQL comme une fin prématurée là où un mysql_close fermerait sans fin prématurée.
    
    Je n'ai pas MySQL sous la main pour faire un test, mais un simple script avec un mysql_connect et un autre avec un connect+close, un coup de `ab` dessus pour l'exécuter 1000 ou 2000 fois et voir la différence dans les stats.

    • [^] # Re: Ah et j'oubliais...

      Posté par Henry-Nicolas Tourneur (site web personnel) le 22 janvier 2009 à 11:33. Évalué à 1.

      

      Oui ça ce serait une explication logique. Néanmoins les sites web ou applications que nous avons écrit et qui tourne en PHP font bien des mysql_close et les autres sont des applications tellement populaires que je leur fait confiance pour des trucs aussi bancal.
      
      J'avais également lu à l'époque de mes premières investiguations que cela pouvait améliorer les choses de désactiver les connections persistantes en PHP, je l'ai fait mais ça ne change rien.

      • [^] # Re: Ah et j'oubliais...

        Posté par newbeewan (site web personnel) le 22 janvier 2009 à 12:11. Évalué à 1.

        

        Franchement, est-ce que cela pose un problème de performance ou de fuite de mémoire dans mysql, php ou cfml ?
        Si la réponse est non, je pense qu'il faut surveiller mais qu'une recherche approfondie sera si cela réellement pose un problème !
        
        Par ailleurs, ce n'est pas parce que un soft est populaire qu'il est correctement codé, par exemple osCommerce (très populaire mais codé avec les pieds)...
        
        Enfin tous les soft codé en php sans utiliser pdo sont susceptibles d'avoir des fuites de connexions mal gérées puisqu'il n'y a pas de gestion clair d'exception et qu'ajouter une gestion d'erreur à chaque requête SQL est très contraignant (donc omise dans la majorité des cas...) !
        
        Si tu dois faire un audit de ces fuites, il n'y a pas beaucoup de solution :
        - Soit tu es capable d'avoir des stats par utilisateur mysql et dans ce cas là, c'est le plus simple : un utilisateur / appli et tu pourras savoir celle(s) qui pose problème.
        - Soit tu ne peux avoir que des stats global et là, c'est pas de chance, il faudra faire tourner une appli seule avec mysql et faire des tests pour voir ce qu'il se passe !
        
        Dans tous les cas bon courage !!!

        • [^] # Re: Ah et j'oubliais...

          Posté par Henry-Nicolas Tourneur (site web personnel) le 22 janvier 2009 à 12:28. Évalué à 1.

          

          En fait il n'y a aucun problème, tout tourne parfaitement, pas de soucis de mémoire ni rien.
          Donc c'est plus pour avoir la sensation d'avoir un setup bien fini qu'autre chose.
          
          Sinon, vu la vitesse à laquelle les connections "aborded" augmente lors d'un redémarrage de MySQL pour arriver à 40%, je pencherai d'office pour une application fort utilisée. Sur ce serveur, ce qui est le plus visité ce sont des sites en CFML (hormis le wrapper php pour maildrop qui est très très utilisé mais lui il est clean).
          
          J'ai lu des articles de comparatif entre l'engine d'adobe et Railo ou on disait entre autre que le connecteur fourni par Railo est un vieux connecteur pour MySQL 3. Je ne sais pas si ça peut poser problème et je vais sans doute devoir bien me renseigner avant d'envisager la mise en place d'un connecteur plus récent.

          • [^] # Re: Ah et j'oubliais...

            Posté par briaeros007 le 22 janvier 2009 à 14:44. Évalué à 2.

            

            tu peux pas modifier les options de log de mysql pour avoir plus d'info à propos des connexion etc?
            ça permettrait sans doute de remonter rapidment à la source des problèmes (surtout si chaque appli à son propre login)
            
            Tu aurais pas aussi des "erreurs" dans ton cfm ? La genre de truc con : dans le code php tu ouvre ta connexion à mysql. Dans certains cas tu as un "exit" dans le code, et avant cet exit tu as pas le mysql_close kivabien.

            • [^] # Re: Ah et j'oubliais...

              Posté par Henry-Nicolas Tourneur (site web personnel) le 22 janvier 2009 à 16:09. Évalué à 1.

              

              Je peut modifier la config de MySQL pour logger plus, ça oui (mais je ne sais pas quelle option il faut utiliser).
              Les applications partagent un login mysql unique (je sais c'est pas super niveau sécu mais tout appartient à la même personne...).
              
              Pour le CFML, c'est railo qui se charge de l'établissement de la fin des connexions, y a pas de connect ou de close en cfml, on spécifie juste une ressource. Mais je suspecte que ça vienne de la à cause du tout vieux connecteur (en v 3.0 au lieu de 5.0).
              
              Pour le PHP je pense pas que le soucis soit là, je dit ça parce-que je sais quel sites représente quoi sur ce serveur et je sais qu'a la vitesse à laquelle on atteint ces 40% de connexions "aborded" ça ne doit être qu'un site fort visité (ou des sites) et là c'est en CFML.
              
              Normalement le connecteur mysql est un .jar, je ne sais pas si je peut me contenter de le remplacer par un plus récent de chez MySQL. Une idée ?

              • [^] # Re: Ah et j'oubliais...

                Posté par briaeros007 le 22 janvier 2009 à 18:23. Évalué à 2.

                

                j'ai fait un peu de google pour trouver où se trouver les options de mysql, et j'avoue que j'ai rien trouvé d'interessant. Et ensuite on dis que postgresql est plus compliqué que mysql (c'est super détaillé dans postgresql.conf)
                
                En ce qui concerne le remplacement, tu peux toujours sauvegarder ton .jar actuel, le remplacer par un plus neuf, et voir si ca marche (de préference quant il y a pas d'utilisateurs XD).
                
                Si l'API a pas changé, cela ne devrais pas poser trop de problème.
                
                Si la connection s'effectue par java, il y a des options étendues de debug avec java (un truc style JRI ou autre, trop compliqué pour ma petite tête).
                
                Il est aussi possible que tu ais des problèmes parce qu'un pool de connection mysql/java est trop faible, et donc il timeout qq nouvelles connections.
                Mais la, idem , je connais pas trop mysql, ni les connecteurs mysql/java/php donc je peux pas trop t'aider.

        • [^] # Re: Ah et j'oubliais...

          Posté par Henry-Nicolas Tourneur (site web personnel) le 22 janvier 2009 à 14:45. Évalué à 1.

          

          Tiens petite question annexe : tu dit que toutes les applis php codées sans pdo sont suceptibles d'avoir des fuites de connexions. Qu'en est-il de adodb ? Il gère ça aussi ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.