Comments on: Debugging sleeping connections with MySQL http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/ Everything about MySQL Performance Fri, 29 Aug 2008 23:22:50 +0000 http://wordpress.org/?v=2.5.1 By: Tom Pittlik http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-184670 Tom Pittlik Mon, 05 Nov 2007 00:58:58 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-184670 I get this once in a blue moon - instead of tracking down what's causing the problem (since it's so rare) i made a simple cronjob that checks if dbconnect() fails for mysql_errno() reason 1040 (too many connections). If it does i run shell_exec("httpd restart") and the sleeping connections are gone. I get this once in a blue moon - instead of tracking down what’s causing the problem (since it’s so rare) i made a simple cronjob that checks if dbconnect() fails for mysql_errno() reason 1040 (too many connections). If it does i run shell_exec(”httpd restart”) and the sleeping connections are gone.

]]> By: peter http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-57819 peter Thu, 22 Feb 2007 09:32:43 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-57819 Guruprasad, I'd check if these connections are associated with open file descriptors. If they are it is likely these are persistent connections which may be reused. If not it is likely these connections are still closing by kernel, sometimes it takes longer time for some reason. Guruprasad,

I’d check if these connections are associated with open file descriptors. If they are it is likely these are persistent connections which may be reused. If not it is likely these connections are still closing by kernel, sometimes it takes longer time for some reason.

]]> By: Guruprasad http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-57523 Guruprasad Thu, 22 Feb 2007 01:24:58 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-57523 Just in case if some one is tryin this on BSD box, netstat -ntp might not work, u can use lsof instead like, lsof -i -P | grep OR Just in case if some one is tryin this on BSD box,
netstat -ntp might not work, u can use lsof instead like,

lsof -i -P | grep OR

]]> By: Guruprasad http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-57520 Guruprasad Thu, 22 Feb 2007 01:19:35 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-57520 Hi, I notice that my apache process is in accept call, i do notice that there are 3 connections to MySQL:3306 and show process list on MySQL indicates they are in sleep state. Is there a way to findout if these connections will be reused by this apache child process at all? Or are these connections more like resource leak? - Thanks, Gp Hi,
I notice that my apache process is in accept call, i do notice that there are 3 connections to MySQL:3306 and show process list on MySQL indicates they are in sleep state.
Is there a way to findout if these connections will be reused by this apache child process at all?
Or are these connections more like resource leak?

-
Thanks,
Gp

]]> By: peter http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55581 peter Mon, 19 Feb 2007 14:58:53 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55581 Sure. Paste GDB backtrace or you can create forum topic and discuss it where. Basically it is waiting on flock() if this is PHP I'd expect it to be session - PHP locks session file for whole script execution duration which may cause problems with a lot of requests from single agent. It may be something in your own code as well. you can use "lsof" to find out what is file #24 in this process Sure. Paste GDB backtrace or you can create forum topic and discuss it where.

Basically it is waiting on flock() if this is PHP I’d expect it to be session - PHP locks session file for whole script execution duration which may cause problems with a lot of requests from single agent.

It may be something in your own code as well. you can use “lsof” to find out what is file #24 in this process

]]> By: Anonymous Coward http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55577 Anonymous Coward Mon, 19 Feb 2007 14:53:53 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55577 Me again... Can you please give more detail on using strace/gdb? i have few mysql that sleep for over 1000 and.. netstat on port gives me # netstat -ntp | grep :51646 tcp 0 0 127.0.0.1:51646 127.0.0.1:3306 ESTABLISHED 32034/apache2 tcp 0 0 127.0.0.1:3306 127.0.0.1:51646 ESTABLISHED 8512/mysqld strace on pid gives me # strace -p 32034 Process 32034 attached - interrupt to quit flock(24, LOCK_EX gdb shows me that it loads some libraries and that's about it application wasn't written by me and im no php/mysql guru, just a part-time sysadmin that wants to solve this problem as usually in 1-2 days mysql conn. limit gets touched and i have to restart apache to fix it Me again…

Can you please give more detail on using strace/gdb?
i have few mysql that sleep for over 1000 and..
netstat on port gives me

# netstat -ntp | grep :51646
tcp 0 0 127.0.0.1:51646 127.0.0.1:3306 ESTABLISHED 32034/apache2
tcp 0 0 127.0.0.1:3306 127.0.0.1:51646 ESTABLISHED 8512/mysqld

strace on pid gives me

# strace -p 32034
Process 32034 attached - interrupt to quit
flock(24, LOCK_EX

gdb shows me that it loads some libraries and that’s about it
application wasn’t written by me and im no php/mysql guru, just a part-time sysadmin that wants to solve this problem as usually in 1-2 days mysql conn. limit gets touched and i have to restart apache to fix it

]]> By: peter http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55545 peter Mon, 19 Feb 2007 12:42:10 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55545 Ok. Good you've figured that you :) Ok. Good you’ve figured that you :)

]]> By: Anonymous Coward http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55538 Anonymous Coward Mon, 19 Feb 2007 12:34:09 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55538 ok i feel kinda stupid now... it was listening in both socket and tcp so the webapp prefered the socket, ill try to change it and see what's causing the sleep processes Thanks for info and keep up the good work ok i feel kinda stupid now… it was listening in both socket and tcp so the webapp prefered the socket, ill try to change it and see what’s causing the sleep processes

Thanks for info and keep up the good work

]]> By: Anonymous Coward http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55534 Anonymous Coward Mon, 19 Feb 2007 12:25:59 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55534 nope, im connecting via tcp mysqld 22241 mysql 11u IPv4 337587343 TCP *:mysql (LISTEN) Even so in phpmyadmin or even in cli i see only localhost with no port... nope, im connecting via tcp

mysqld 22241 mysql 11u IPv4 337587343 TCP *:mysql (LISTEN)

Even so in phpmyadmin or even in cli i see only localhost with no port…

]]> By: peter http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55529 peter Mon, 19 Feb 2007 12:12:45 +0000 http://www.mysqlperformanceblog.com/2007/02/08/debugging-sleeping-connections-with-mysql/#comment-55529 Well, in this case you're connecting from the same host via unix socket. In this case such information is unavailable. If you need to debug something you can use 127.0.0.1 so connection will happen via TCP/IP Well, in this case you’re connecting from the same host via unix socket. In this case such information is unavailable.

If you need to debug something you can use 127.0.0.1 so connection will happen via TCP/IP

]]>