We have a "NOC" that displays this sort of thing and shows myTop in six
windows for DEV/TEST/PROD and Master/Slave for
each.(http://www.daevid.com/content/examples/snippets.php scroll down to
"Automatic Monitoring of remote servers" for a handy script)
So we do monitor this and will kill long running queries by hand. I was
hoping for something a little more automated however. It just seems odd to
me that PHP does a mysql_connect and gets a resource ID. Then it uses that
socket (or whatever it is) to do subsequent queries. Mysql has to know about
it too in order for it to send back results to the same
resource/handle/socket/whatever. So either PHP should do some cleanup, which
I assume it does when the page goes away, otherwise PHP would leak memory
like a sieve all over the place as pages are closed/aborted, OR mySQL should
get a signal that, "hey, your handle to return your data on just STB, so
stop what you're doing please".
On a related note then, is there a way to set a my.cnf setting so that
queries that are going for longer than X seconds are re-niced or something
to not bog down the system? Ideally I'd assume you'd want each query to "peg
the CPU" so that they're in and out quickly and the user can get on with
their life. But these long running ones at some point X are then taking over
the entire server with 135% CPU usage and killing the experience for any
other user on the web site -- and for a duration too!
> -----Original Message-----
> From: Darryle Steplight [mailto:dsteplight@stripped]
> Sent: Wednesday, June 03, 2009 8:41 AM
> To: Jerry Schwartz
> Cc: Jay Blanchard; Daevid Vincent; mysql@stripped
> Subject: Re: Why doesn't mySQL stop a query when the browser
> tab is closedL
> Hi Daevid,
> You can always stop the query by running
> SHOW PROCESSLIST;
> from the command line or your MySql Admin tool. The above command will
> show you all of the queries that are currently running along with
> their PID# and state. Find the query your want to stop, and run the
> following command
> KILL #; (where # is the process id)
> As far as the relationship between killing queries and the browser, I
> think the previous comments pretty much summed it up.
> On Wed, Jun 3, 2009 at 10:22 AM, Jerry Schwartz
> <jschwartz@stripped> wrote:
> >>-----Original Message-----
> >>From: Jay Blanchard [mailto:jblanchard@stripped]
> >>Sent: Wednesday, June 03, 2009 8:46 AM
> >>To: Daevid Vincent; mysql@stripped
> >>Subject: RE: Why doesn't mySQL stop a query when the browser tab is
> >>I just noticed a horrible thing.
> >>Keep in mind that the query event is server side and is not
> tied to the
> >>browser (client side) once it has begun because of the
> statelessness of
> >>the connection. You would have to have some sort of
> onClose() event from
> >>the browser that would trigger a query cancellation.
> > [JS] Going beyond that, the browser is at several removes
> from the MySQL
> > server. Typically the browser talks to the web server, then
> the web server
> > runs some application code (PHP or whatever), and then the
> application code
> > talks to the MySQL server. The only part of this chain that
> "knows" what the
> > MySQL server is doing is the last bit, the application
> code, which is
> > typically waiting for a response.
> > Getting back to the user, HTTP itself is a stateless
> protocol. That means
> > the web server has no way of knowing if the user, the
> browser, or even the
> > user's computer is still there; it also doesn't really know
> what the user
> > last did (it's up to the application code to remember that somehow).
> > In order for an end user to cancel a query, there would
> have to be some way
> > for the user to tell the browser to tell the web server to tell the
> > application code to tell the MySQL server to stop. I'm
> pretty sure you could
> > create a "tired of waiting" button for the user, but I
> haven't done it
> > myself.
> > Regards,
> > Jerry Schwartz
> > The Infoshop by Global Information Incorporated
> > 195 Farmington Ave.
> > Farmington, CT 06032
> > 860.674.8796 / FAX: 860.674.8341
> > www.the-infoshop.com
> >>MySQL General Mailing List
> >>For list archives: http://lists.mysql.com/mysql
> >>To unsubscribe: http://lists.mysql.com/mysql?unsub=1
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe:
> A: It reverses the normal flow of conversation.
> Q: What's wrong with top-posting?
> A: Top-posting.
> Q: What's the biggest scourge on plain text email discussions?