Thanks for the nice explanation. I was just curious thats all :). Manohar
On Fri, May 29, 2009 at 6:53 PM, Kay Röpke <[email protected]> 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 <[email protected]> wrote: >> >>> I get this error everytime I start 0.7.1 on Fedora Core release 3 >>> (Heidelberg), >>> >>> [r...@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 : [email protected] >>> 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 : [email protected] >> 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
_______________________________________________ Mailing list: https://launchpad.net/~mysql-proxy-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~mysql-proxy-discuss More help : https://help.launchpad.net/ListHelp
