Brett Paden wrote:
And just to be clear, I am able to reproduce this problem on any
tcp connection to any port (not just mysql). We first noticed it in our
production network on mysql, but were able to see it in our proxy =>
backend layer as well as backend => backend layer (ftp/ssh).
That's right.
We also noticed the problem in our production environment with
webservers connecting to mysql databases. But as Brett already said it's
not a mysql issue! We can reproduce it with a simple C program on any
port (independent of mysql).
What we noticed is that there is always a "pair" of client and server
affected. That means: we have M webserver and N database server. When
the problem occures, one of the webserver has 3 second timeouts to one
of the database servers. But the same webserver can connect to all other
database servers without any problems and even the database server
itself can handle connections from all other webservers except the one
affected.
Kind regards,
Leo
I have attached the perl script I use to collect data and to
articifically generate the timeouts (requires the non-stanard
Getopt::Declare module).
Typical usage is something like:
tcptest multdb.pn -f
or for many hosts using port 80 and sleeping 100ms in between
tcptest -rf host1 host2 host3 -p http -u 100000
on Wednesday, Apr 02, 2008, Gabriel Barazer, wrote:
On 04/01/2008 11:30:43 PM +0200, Bernd Eckenfels <ecki@xxxxxxxxxxxx> wrote:
In article <47F29777.6020400@xxxxxxxx> you wrote:
I'm not sure what do you mean by "mass produce" connections, but even
with only 200 connections/sec to the mysql-server the delay occured.
Just an unrelated question: why dont you use a connection pool in this
scenario. With Oracle for example that would totally break down, a typical
connect takes 80-130ms with Oracle on *ix.
[off-topic]
There is a very good reason, and the Oracle example you give is the one I
use for comparison when I am asked this. You are far from being the first
one to ask this very legit question :)
MySQL compared to Oracle has a _very_ low connection overhead by design
(~1ms), and also opposed to Oracle, has weaknesses to manage high number of
permanent connections (mainly because of the memory management). Besides,
there are several cons using the same connection: transactions not properly
reset, latent session-level variables, etc. and other MySQL-specific
features. You can't really have a "clean" environment when using an already
used connection thread with MySQL.
This is also why MySQL became so popular among web/php programmers: because
the concept of connecting/querying/closing a mysql resource in the same
script is very easy to understand (and the only way to do with CGI scripts)
and MySQL makes it viable thanks to its low connection overhead.
This article may be of interest for further information:
http://www.mysql.com/news-and-events/newsletter/2002-11/a0000000086.html
[/off-topic]
Back to the topic :)
Gabriel
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
