>   The good solution for this would be to put OOPS behind of apache.

What is OOPS ?

Is it like SQL Relay ? Others have said that we should be using a 
connection pooler & that it's a PHP/Apache config problem that we're 
running into. We may also move to BSD from Redhat.

 > P.S Are you using mysql binary or version compiled with patched GLIBC
 > if not the threads limit should be the cause.

We had to use the patched glibc. We have over 1,000 connections 
supported now.

- Sam.

On Monday, March 11, 2002, at 06:06 AM, Peter Zaitsev wrote:

> Hello Michael,
>
> Monday, March 11, 2002, 3:38:28 PM, you wrote:
>
>
> I had a close problem once -  then having many active connections (and
> so threads) mysql speed may degrade a lot because of scheduling and
> convergency problem. This does not explain the mysql lock itself, but
> may be the reason (i.e too many threads may make mysql to lock or
> crush because of GLIBC limits)
>   The good solution for this would be to put OOPS behind of apache.
> This gives two positive issues:
>   - your apache server will have much less children and so will require
>   much less memory and will basically work faster. In my case the
>   number of children have dropped from 150 to 16 and required memory
>   from about 1G to 200M (I'm running very complicated PHP scripts)
>   - you will need much less number of connections for mysql.  In my
>   case the number have dropped from about 500 connections from web
>   server to 50, and load average on mysql server fell from 3.0-4.0 to
>   0.5-1.0.
>
>
> P.S Are you using mysql binary or version compiled with patched GLIBC
> if not the threads limit should be the cause.
>
>
> MW> Hi!
>
> Sam>> We have a very high volume site (3 million page views a day) 
> that's run
> Sam>> on 16 Apache / PHP web servers & 2 MySQL servers. We are using 
> PHP with
> Sam>> persistent connections. Each MySQL serves 8 web servers & is 
> supposed to
> Sam>> act as a failover machine for the other group of 8 web servers.
> Sam>>
> Sam>> The failover won't work now as if one MySQL goes down the cost of 
> the 8
> Sam>> web servers switching over is so high the other MySQL locks up.
> Sam>>
> Sam>> Each Apache / PHP server takes up hundreds of connections even 
> when
> Sam>> they're idle so we ran into the Linux connection limit of 1000 & 
> had to
> Sam>> recompile to get past that.
> Sam>>
> Sam>> Our actual MySQL CPU useage is low but the goes when with the 
> connection
> Sam>> overhead when starting up or failing over a bank of machines.
> Sam>>
> Sam>> We get a mysterious MySQL lockup once a week at the same day & 
> time.
>
> MW> Could you please describe the lookup, exactly what happens ?
>
> MW> What does 'mysqladmin var ext' show when this happens?
> MW> What do you have in your log files ?
>
> Sam>> Questions :
> Sam>>
> Sam>> - Is our configuration of 2 sets of 8 Apache/PHP web servers & 1 
> MySQL
> Sam>> servers just not a good idea ?
>
> MW> This should not be a problem.
>
> Sam>> - Would we better off with FreeBSD ?
>
> MW> If you are running a CMP machine, then Linux preforms normally 
> better
> MW> than FreeBSD.
>
> MW> To be able to give some recommendations we need to know more about
> MW> this setup.
>
> Sam>> - Is there anyone doing any similar setups with lots of web 
> servers & a
> Sam>> few MySQLs ?
>
> MW> We have several hundred of paying support customers with this setup.
>
> Sam>> - Is there any way to get Apache / PHP to use fewer connections ?
>
> MW> Stevens Rousseys exellent answer should help you with this
>
> Sam>> We pay for MySQL support but haven't had much help from them.
>
> MW> I checked our support email archive, but couldn't find anything from
> MW> you or your company in it.
>
> MW> Could you please use our supportwizard interface to make a ticket of
> MW> this problem so that we can help you with it?
> MW> If you have already a ticket, please email me the ticket number so
> MW> that we can check this up.
>
> MW> Regards,
> MW> Monty
>
>
>
>
> --
> Best regards,
>  Peter                            mailto:[EMAIL PROTECTED]
>

Reply via email to