mysql-proxy-discuss team mailing list archive

[Kay Röpke <Kay.Roepke@xxxxxxx>]

On May 29, 2009, at 3:33 AM, Diego Medina wrote:

> Hi Manohar,
>
> Yes, it is ok to ignore that error. I guess we should really try
> something different here.
>
> Basically, the proxy tries to increase the number of file descriptors
> it uses, but as your limit is higher, it returns an error. (Maybe Kay
> or Jan have a better description :) )

Almost :)

For the Enterprise Monitor Agent (which uses MySQL Proxy), we have  
found that users often forget to increase the max_open_files when  
starting it.
As Proxy requires two file descriptors for each connection going  
through it (client and server connection, when not using connection  
pooling) many have quickly exhausted the allowed number of open files  
per process (the default often is 512 limiting you to around 250  
connections: we need a couple of file descriptors for other purposes,  
such as log files, stderr and in the agent there are a number of other  
connections going on all the time).
That's when things quickly start to go wrong as you can imagine :)

We decided that the best option would be to try to raise the number of  
open files, and arbitrarily picked 8192 as a default because it looks  
good and is generally high enough.
Now, the error message can occur in two circumstances: Either the user  
who's executing the process isn't allowed to raise the limit (exceeds  
the hard limit set for that shell) or, and this is your case, the  
system returns a very high number for the max allowed file descriptors.
The code checks the upper limit and tries to determine if the value  
the user gave (via --max-open-files= or the default value we set it  
to) exceeds that number. If that's so, we print a warning that you  
should raise the hard limit for this process. This doesn't happen in  
your case, as the limit is reported as 34359739392.
The problem then is, 34359739392 isn't the limit. Not even close. I  
bet if you check ulimit -n it will say "unlimited" (as you are root  
here).
But the getrlimit call doesn't return a 0 to signify "unlimited" -  
instead it returns a ridiculously high number.
We take that number, in good faith, and feed it back to setrlimit if  
the user hasn't specified a value. That system call fails for some  
reason on some platforms, because the system rejects setting ulimit -n  
via setrlimit to the value getrlimit gave us.

Confused yet? Yeah me, too. So far I haven't found a reliable way to  
determine the allowed values for all the different platforms. However,  
in most cases, if your original limit was high enough, this is not a  
problem. The "critical" message is simply there because there's no  
straightforward way to detect this scenario - it's a "false positive"  
if you will.

Hopefully with 0.8 this message will go the way of the Dodo when the  
improved logging system is the default.
Until then, please accept my apologies for the badly worded and  
slightly discomforting critical message :(

cheers,
-k

> On Thu, May 28, 2009 at 2:05 PM, manohar s <manoharyes@xxxxxxxxx>  
> wrote:
> > I get this error everytime I start 0.7.1 on Fedora Core release 3
> > (Heidelberg),
> >
> > [root@testserver /]# uname -a
> > Linux testserver 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005  
> > i686
> > athlon i386 GNU/Linux
> >
> > Error:
> >
> > 2009-05-28 23:29:23: (critical) chassis.c:980: could not raise  
> > RLIMIT_NOFILE
> > to 8192, Invalid argument (22). Current limit still 34359739392.
> >
> > Is this expected?
> >
> > Manohar
> >
> > --
> > hope is the only thing which keeps us all happy
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~mysql-proxy-discuss
> > Post to     : mysql-proxy-discuss@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~mysql-proxy-discuss
> > More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> Diego Medina
> Web Developer
> http://www.fmpwizard.com
>
> _______________________________________________
> Mailing list: https://launchpad.net/~mysql-proxy-discuss
> Post to     : mysql-proxy-discuss@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~mysql-proxy-discuss
> More help   : https://help.launchpad.net/ListHelp

--
Kay Roepke
Software Engineer, MySQL Enterprise Tools

Sun Microsystems GmbH    Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer:    Thomas Schroeder,  Wolfang Engels,  Wolf Frenkel
Vorsitz d. Aufs.rat.: Martin Haering                    HRB MUC 161028