-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adam B. wrote:
I don’t think “clearly” can be used in this context. The “Lost
connection to MySQL server…” error that you most likely seeing is
one where a dispatcher has an OLD mysql connection.
Zach, this is good information but doesn’t explain why I never have this
problem when I am using PStore (where there of course is AR activity in
the DB, just not session-related).
I don’t know the exact scenario you’re hitting, but with PStore you’re
not dealing with MySQL for session data. So you bypass having to hit
MySQL altogether. So even if the problem did exist you may not be seeing
it because of using PStore.
Also, and I wasn’t clear about this in my first posting, I can fix the
problem by refreshing the page a few times; it always load eventually.
This is probably the result of using a fresh dispatcher, or eventually
getting a good dispatcher. Keep reading for more information.
So it doesn’t appear as if MySQL is refusing all requests.
MySQL isn’t refusing requests. The "Lost connection to … " error
indicates that there was a connection between a MySQL client and server
already made, and that the client has sent a query to the server, but
either:
a - never heard back from the server at all
b - didn’t hear a complete message back from the server
“a” is usually the case because after 8 hours of inactivity from a
connection, the server will disregard any future requests.
Though I know
almost nothing about dispatchers; AWDWR has little to say about them.
When you run your rails application using Apache or Lighttpd you run
more then one instance of your application. If you do a “ps ax | grep
dispatcher” you’ll probably see multiple instances.
Rails is setup to run as a FastCGI process, which is a way that allows
Apache and Lighttpd to reuse existing processes for processing incoming
requests.
Based on your Apache/Lighttpd configuration you will have a minimum
number of dispatchers always running by default. When your server gets
hit by alot of people more dispatchers will be started (this is the
#{RAILS_ROOT}/public/dispatch.fcgi file) by Apache/Lighttpd. Those
dispatchers usually remain in existence for a set period of time, until
they’re not needed or forever. It depends on your configuration.
To give you a simplified example scenario of what I think might be
happening.
- Apache starts, and spawns 3 dispatcher processes.
- Each dispatcher starts up and creates a database connection to the
server
- Over the next 8 hours you never have more then 2 concurrent users
which mean the first two dispatcher’s will service those requests
- After eight hours you get 3 concurrent users.
- The third user goes to the third dispatcher process and you receive
the “Lost connection to …” error.
Why does this happen? Because the third dispatcher created a connection
to the MySQL database over 8 hours ago, and the connection has
essentially timed out.
Is
there a recommended way of doing your #2?
I don’t know your setup or your requirements, and I am not necessarily
recommending that you do this, but I am giving you this information so
you can evaluate the needs of your environment and your application.
I would start with option #3 rather then #2. Increase the wait_timeout
in your mysql server configuration to 24 hours or even longer.
If you still need do #2, then create a cronjob which kills dispatcher
processes in the middle of the night. Your web server will respawn them.
This should take a split second to do this.
You should of course test any of this. Do note that I’ve seen varying
results for how efficiently Apache2 and Lighttpd respawns dispatcher
processes. On shared web hosts like dreamhost it can take up 15 minutes,
which is NOT ideal, but on actual production systems that I run it is
NOT a problem.
Zach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFjMOFMyx0fW1d8G0RAvrnAJ9vGfPgNNGkUoGJ9UpAlk7gmM1YYwCaAtgk
KTr6A8VRTxhwsIGL01I5ULI=
=/tjX
-----END PGP SIGNATURE-----