Je suis en train d'exécuter une connexion printemps / hibernate à la configuration MySQL à l'aide de C3P0 comme piscine de connexion. Pour certaines raisons bizarres, il est sorti des connexions lorsque le système est sous charge (bien sûr).
Le site était assez stable jusqu'à ce que nous ayons commencé à frapper un nouveau niveau de trafic (plus de centaines d'utilisateurs simultanés). À ce moment-là, la DB ferait fondre (PEG THE CPU). Ma première action était dans la demande visant à améliorer les performances grâce à une mise en cache et à une optimisation approfondie des requêtes, etc. p>
Il sera maintenant à court de connexions par intermittence. Cela ne semble même même pas si dépendant de la charge. Plus à temps, ce qui me fait penser que c'est une fuite, mais pour la vie de moi, je ne peux pas comprendre où cela arriverait. P> Voici ma configuration: P> <bean id="openSessionInViewInterceptor" class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">
<property name="sessionFactory">
<ref bean="sessionFactory" />
</property>
<property name="flushModeName">
<value>FLUSH_AUTO</value>
</property>
</bean>
5 Réponses :
Il est assez improbable que Mais il y a une autre raison pour laquelle cela se produit:
Peut-être que vous avez défini un délai d'attente pour les connexions "mortes" et certaines requêtes prennent plus de temps que cela. Cela signifie que votre piscine a retiré une connexion occupée comme "morte" de la piscine et en demande un autre à partir de la DB - jusqu'à ce que le dB tire la fiche.
Pour déboguer ceci, activer la journalisation pour votre pool de connexion, vous pouvez donc voir quand il demande de nouvelles connexions. @Transactional Les connexions de fuite - sinon, votre site cesserait de fonctionner après les 100 premières demandes.
Mon maxconnection a été défini sur 14400, qui, selon la documentation, se trouve en secondes (non ms) afin que ce soit 240 minutes. Malade définitivement essayer d'allumer la journalisation. Le problème est qu'il s'ouvre et ferme une tonne de connexions alors isolant là où elle se produise est difficile. Surtout sous charge.
Essayez d'activer la journalisation et la définition du S'il n'y a pas de motif aux traces de la pile, cela pourrait être que votre piscine est trop petite. Vous avez dit 100 utilisateurs simultanés, mais aucune idée du nombre de requêtes par seconde c'est? S'il s'agit de 100 requêtes par seconde et que vous disposez de 20 connexions, chaque exécution SQL doit alors prendre moins de 200 ms (20 connexions => 20 secondes totales de travail par seconde du temps d'horloge murale pour effectuer 100 requêtes). C3P0.debugunreturnedConnectionStackTraces propriété sur true. Également défini c3p0.unreturnedConnectionTimeTTimeout à quelque chose de plus petit que votre temps de requête moyen (1 sece?). Ensuite, toute chose qui prend plus de temps que le délai d'attente enregistre une trace de pile. Cela devrait vous permettre de réduire les choses assez rapidement.
Quelle que soit la configuration que vous avez pour C3P0 (via Hibernate), vous pourriez avoir une restriction imposée par MySQL elle-même. Gardez à l'esprit que par défaut, le nombre maximum de connexions autorisées par MySQL est 100! Donc, même si vous dites à C3P0 de mettre en commun jusqu'à 200, 500 ou 1000 connexions, cela sera irréalisable. Ouvrez une coque MySQL en utilisant: et tapez les éléments suivants pour obtenir le nombre maximal de connexions autorisées: si le nombre renvoyé est Trop basse pour votre application, envisagez de le changer (modifiez votre fichier My.cnf, généralement situé à l'intérieur / etc / mysql / sur les systèmes Linux).
J'ai aussi eu ce problème. La cause était que l'utilisateur ne dispose pas des subventions pour l'hôte, car l'entrée / etc / hosts a été modifiée.
J'ai aussi eu ce problème et je l'ai résolu en réglant la propriété En fait, j'avais beaucoup de threads en attente d'une connexion et après 10 ans, les mêmes erros que la vôtre se produisait.
Voir la doconique ici: http://www.mchange.com/projects/c3p0/ #checkoutTimeout