mysql-proxy-discuss team mailing list archive

[manohar s <manoharyes@xxxxxxxxx>]

Thanks for the nice explanation. I was just curious thats all :).

Manohar

On Fri, May 29, 2009 at 6:53 PM, Kay Röpke <Kay.Roepke@xxxxxxx> wrote:

>
> 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<https://launchpad.net/%7Emysql-proxy-discuss>
>>> Post to     : mysql-proxy-discuss@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~mysql-proxy-discuss<https://launchpad.net/%7Emysql-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<https://launchpad.net/%7Emysql-proxy-discuss>
>> Post to     : mysql-proxy-discuss@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~mysql-proxy-discuss<https://launchpad.net/%7Emysql-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
>
>


-- 
hope is the only thing which keeps us all happy