MySQL ODBC Connector - Too many Mysql processes at startup after upgrade to 4.1.14

Author

Too many Mysql processes at startup after upgrade to 4.1.14

Kishore Jalleda

2005-09-15, 1:23 pm

------ =_Part_33044_1307083
9.1126805971609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi All,
Last night I upgraded our Master server to 4.1.14 standard log from 4.0.17=
,=20
I upgraded the slave a week ago and the replication was working perfectly,=
=20
once I upgraded and started mysql, it started fine without any errors but=
=20
the server was steadily creating mysql processes at the rate of like 20/sec=
=20
until it reached the Max_connections limit set at 800, while it was doing=
=20
this it was serving the web clients only randomly , also the load was very=
=20
very low neither was it taking up any memory, it was just creating processe=
s=20
, I remember seeing this behaviour even earlier with 4.0.17 when the server=
=20
just started but after a certain point the no of processes return to normal=
..
So I had to switch back to 4.0.x, and it works perfectly fine, Also I did=
=20
not dump the databases just zipped the old datadir and unzipped it into the=
=20
new datadir, anybody else experience this behaviour at startup( I am aware=
=20
that once the server is back online it is flooded with requests), the OS is=
=20
Redhat 7.3, the server currently does 200-400 qps quiet comfortably .
Any help would be appreciated, let me know if you need more info
Kishore Jalleda

------ =_Part_33044_1307083
9.1126805971609--

Gleb Paharenko

2005-09-16, 8:23 pm

Hello.

What is SHOW PROCESSLIST reporting when the server is reaching the
max_connections limit?

Kishore Jalleda <kjalleda@gmail.com> wrote:
>Hi All,
> Last night I upgraded our Master server to 4.1.14 standard log from 4.0.17,
>I upgraded the slave a week ago and the replication was working perfectly,
>once I upgraded and started mysql, it started fine without any errors but
>the server was steadily creating mysql processes at the rate of like 20/sec
>until it reached the Max_connections limit set at 800, while it was doing
>this it was serving the web clients only randomly , also the load was very
>very low neither was it taking up any memory, it was just creating processes
>, I remember seeing this behaviour even earlier with 4.0.17 when the server
>just started but after a certain point the no of processes return to normal.
> So I had to switch back to 4.0.x, and it works perfectly fine, Also I did
>not dump the databases just zipped the old datadir and unzipped it into the
>new datadir, anybody else experience this behaviour at startup( I am aware
>that once the server is back online it is flooded with requests), the OS is
>Redhat 7.3, the server currently does 200-400 qps quiet comfortably .
> Any help would be appreciated, let me know if you need more info
> Kishore Jalleda

--
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.NET http://www.ensita.net/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Gleb Paharenko
/ /|_/ / // /\ \/ /_/ / /__ Gleb.Paharenko@ensita.net
/_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET
<___/ www.mysql.com

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw

Chris Allen

2005-09-16, 8:23 pm

I don't know if this is relevant to you - but I had exactly
the same experience when upgrading to MySQL v4.1. It turned out
that MySQL was trying to do reverse DNS lookups before authenticating
the connecting hosts - and was failing slowly on each because the database
machine didn't have external net access.

Adding all the local machines to /etc/hosts solved the problem
immediately.

Chris Allen.

On Fri, Sep 16, 2005 at 01:30:34PM +0300, Gleb Paharenko wrote:
> Hello.
>
>
>
> What is SHOW PROCESSLIST reporting when the server is reaching the
>
> max_connections limit?
>
>
>
>
>
>
>
>
>
> Kishore Jalleda <kjalleda@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> For technical support contracts, goto https://order.mysql.com/?ref=ensita
> This email is sponsored by Ensita.NET http://www.ensita.net/
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Gleb Paharenko
> / /|_/ / // /\ \/ /_/ / /__ Gleb.Paharenko@ensita.net
> /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET
> <___/ www.mysql.com
>
>
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=lists@cjx.com
>

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql? unsub...sie.nctu.edu.tw

Kishore Jalleda

2005-09-16, 8:23 pm

------=_Part_6931_8776651.1126901868779
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,=20
Unfortunately I dint check SHOW PROCESSLIST as I was overwhelmed with the=
=20
state of the server and had to bring back the old version online, but the=
=20
reverse DNS lookups could be the reason, but surprisingly it was infact=20
serving some client requests
, also is there a way to stop mysql from doing reverse DNS lookups ..
Thanks=20
Kishore Jalleda=20
On 9/16/05, Chris Allen <lists@cjx.com> wrote:=20
>=20
> I don't know if this is relevant to you - but I had exactly
> the same experience when upgrading to MySQL v4.1. It turned out
> that MySQL was trying to do reverse DNS lookups before authenticating
> the connecting hosts - and was failing slowly on each because the databas=
e
> machine didn't have external net access.
>=20
> Adding all the local machines to /etc/hosts solved the problem
> immediately.
>=20
> Chris Allen.
>=20
>=20
>=20
> On Fri, Sep 16, 2005 at 01:30:34PM +0300, Gleb Paharenko wrote:
=20[color=darkred]
> 4.0.17,
> perfectly,
=20[color=darkred]
> but
=20[color=darkred]
> 20/sec
> doing
=20[color=darkred]
> very
> processes
=20[color=darkred]
> server
=20[color=darkred]
> normal.
=20[color=darkred]
> did
o=20[color=darkred]
> the
=20[color=darkred]
> aware
=20[color=darkred]
> OS is
> https://order.mysql.com/?ref=3Densita
>=20
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql? unsub...ma
il.com
>=20
>

------=_Part_6931_8776651.1126901868779--

Sponsored Links