Hi,
> It sounds like you're more interested in the number of active
connections that can be 
> maintained, in which case the max_connections variable is likely to be
of more use to you.

I set the variables max_connections to 700 and back_log to 600. My
server can maintain it.
The problem that I want identified is which server between MySQL server
and HTTP server
has limit to handle the maximun number of connections that it can do to
interact with another one.

Also the MySQL server has during the periodes of strong load less than
420 connections.
The CPUs (2 CPUs) and memory (up to 2.5 Gb) utilisation are correct when
it happens.
I rarely have a so pretty busy MySQL server.

The HTTP server has lot of CPU (1 CPU) and memory (up to 3 Gb) resources
available while it reached the maximun number of clients. But in this
server (HTTP), it often happens that 
it cannot treat any more the connections requests to the MySQL server or
connections responses
from the MySQL server. And in this case it is blocked for a while. 
to resolve this, I often restart the httpd (daemon) to resolve blocking
state.

That is why I suspect the system resource <listen queue size> to can be
the bottleneck.

Any advice will be appreciated
think in advance

-----Original Message-----
From: Paul DuBois [mailto:[EMAIL PROTECTED] 
Sent: mercredi 30 juillet 2003 15:21
To: Thierno Cissé
Cc: [EMAIL PROTECTED]
Subject: RE: how listen queue size affect MySQL on RedHat


At 14:55 +0000 7/30/03, Thierno Cissé wrote:
>Hi Paul Dubois,

Please reply to the list, not just to me directly.  Thanks.

>we late to answers due to administration problems.
>>  MySQL doesn't have anything to do with HTTP connections.
>Next is an extract of MySQL documentation (MySQL reference manual up to

>Version 4.1.0-alpha).
>
>...In other words, this value is the size of the listen queue for 
>incoming TCP/IP connections. Your operating system has its own limit on

>the size of this queue. The manual
>page for the Unix listen(2) system call should have more details. Check
>your OS
>documentation for the maximum value for this variable. Attempting to
set
>back_log
>higher than your operating system limit will be ine®ective.
>
>And , in relation to back_log=600 variable in my my.cnf file, I want to

>know if there is an effect to setting this variable with a value higher

>that system parameter
>listen queue size ?
>This response will help to determine the causes of bugs which appears
>in our web site as soon as apache HTTP processes which interact with
>MySQL server
>tends to higher value like 300-400 process .
>Think in advance

back_log refers to the size of the queue for connections that have not
yet been accepted (though the precise semantics for this may depend on
your operating system.  For example, the meaning of "queued" on Linux
appears to have changed with Linux 2.2, according to my listen(2)
manpagge.)

It sounds like you're more interested in the number of active
connections that can be maintained, in which case the max_connections
variable is likely to be of more use to you.

With respect to setting back_log higher than the value allowed by your
operating system, it's just as the MySQL manual says:  Setting it higher
than the OS limit won't get you anything.  (How could it? The OS won't
let you exceed its own limit.)

Also, it's not clear from your message whether the "bugs" to which you
allude above are problems with your web server (and its connections), or
connections between your web server and your MySQL server... depends on
what symptoms you're observing.

>
>-----Original Message-----
>From: Paul DuBois [mailto:[EMAIL PROTECTED]
>Sent: mercredi 30 juillet 2003 04:44
>To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: how listen queue size affect MySQL on RedHat
>
>
>At 14:53 +0000 7/29/03, <[EMAIL PROTECTED]> wrote:
>>Hi all,
>>i want to know if the system parameter somaxconn affect the 
>>capabalities of MySQL to maintain more than five thousands of HTTP 
>>connections ? If so , any clarifications may help. think in advance
>
>MySQL doesn't have anything to do with HTTP connections.
>What are you really asking?


-- 
Paul DuBois, Senior Technical Writer
Madison, Wisconsin, USA
MySQL AB, www.mysql.com

Are you MySQL certified?  http://www.mysql.com/certification/


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:
http://lists.mysql.com/[EMAIL PROTECTED]


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to