Re: [caudium-devel] Limits and performances

[Marek Habersack <grendel AT caudium.net>]

On Thu, Feb 23, 2006 at 04:47:43PM +0100, Bertrand LUPART scribbled:
> >>After some discussion with Tamas on IRC, it seems that those are
> >>system-wide, maybe deprecated on 2.6 and won't help Caudium to open
> >>more than 1024 files at a time.
> >>I guess "ulimit -n xxxx" would help when invoqued from /etc/init.d/
> >>caudium script. If so, it should be put into caudiumctl, too.
> >>
> >>Can a Linux guru emphasize on this?
> >Linux 2.6 sets the maximum file descriptors number based on the  
> >host memory
> >size, you can see what's your maximum limit by looking at:
> >
> >$ cat /proc/sys/fs/file-max
> >101642
> >
> >The limit of 1024 descriptors is the default system resource limit  
> >for a user
> >account. You can change it using ulimit as you've put it above, or  
> >you can
> >modify /etc/security/limits.conf to set the limit for the given user 
> >(s) or
> >group(s).
> 
> The user can't change that himself. So, you have to change that with  
User can change the limits within the hard limit boundaries set up in
limits.conf. They default to the soft limit specified therein.

> a privileged user and should apply to the child process then? All the  
> doc i've found about this on the net don't make that clear.
Yes, it is inherited by all the child process of the user's login shell (or
whatever parent program set the limits, e.g. apache or caudium)

> On my Sarge machine, the man page for limits.conf(5) doesn't match  
> with the format of /etc/security/limits.conf. I didn't succeed  
> increasing the nofile for my users using /etc/security/limits.conf.
Have you tried this:

@usergroup      soft    nofile          2048
@usergroup      hard    nofile          3092

or

username        soft    nofile          2048
username        hard    nofile          3092

and made sure that your /etc/pam.d/ssh has

session         required        pam_limits.so

It should work if set up as above.

> >Putting it into caudiumctl is not a good idea, IMHO, since the
> >descriptor limit for a user/process is a matter of system policy  
> >and not of
> >application configuration, although there should be a mechanism for an
> >application to raise its limits if that's allowed by the admin. If  
> >we are to
> >do it, then I'd propose using the appropriate POSIX API, that way  
> >it would
> >work on any system regardless of whether or not ulimit can be used  
> >there
> >(ulimit is a bash built-in, not an external command, so putting it in
> >caudiumctl would be assuming it will always be ran by bash, which  
> >is very
> >often not true).
> 
> Would that be a problem if that would be an application configuration?
No, I don't think it would, as long as it can be set in an external config
file and is set programmatically from within the application.

> 
> For increasing the limits for Caudium, you'd have to be able to  
> increase the limit for the user Caudium uses on your system. The  
> Caudium admin may not have the rights nor the skills  for setting  
> that up (still wondering why this doesn't work on my sarge, still  
> looking for documentation for darwin).
Well, no matter how you implement it in caudium, it won't be able to raise
the limits above the system default, so the admin has to set the 1024 fds
limits outside caudium anyway. If you want to make default limits for the
root user (note though that they will NOT be obeyed on the system startup),
then I'd suggest configuring limits.conf for the root user as you prefer,
and then using

sudo su -

to become root (su uses pam)

As for the system startup, there used to be a way to set the default limits
on the linux command line (from the bootloader), but I forget what was it. I
will try to find it tonight and post here how to do that.

> Then, if you use the same user for others things (say, CGI scripts),  
> you allow these other programs the same increased limits.
Well, that's where the application kicks in - it needs to lower the limits
of the CGI scripts before launching them (and I think Caudium does that in
the CGI module). As an aside, the Unix limits system is pretty icky, IMHO,
as there is no way (in most OSes - Solaris 10+ has the compartments to do
that) to set cumulative limits for a group of processes, which would be
useful for applications that spawn multiple copies of self.

> 
> >>What about using rlimit in Process.create_process()->create() in
> >>start-caudium?
> >Yep, that's a much better idea. Either that or we could use  
> >setrlimit(2),
> >which is supported by BSDs, SVr4, Linux and POSIX, so it's fairly  
> >common.
> 
> I just added a page in the Status CIF page for being able to easily  
> check the current limits.
> 
> If i understand well, we could increase the limits using:
> 
> - start-caudium (which is often launched as root).
Again, we cannot increase them above whatever is set for the shell/process
by which caudium is started.

> - the CIF:
>       - on the fly using setrlimit(2) if Caudium is run as root;
setrlimit works for non-root users too, but only for making the limits
smaller (within the bounds of the soft+hard limits of the user's parent
process)

>       - after a reboot if the limits are stored in Global_Variables and  
> Caudium doesn't run as root;
Well, see above - that won't work as expected unless init(8) is run with
correct default limits.

> start-caudium don't have a portable configuration file. What about  
> storing that in Global_Variables? start-caudium already read and  
> parse it.
I think it would be better to pass them on the command line as well. That
way it would be more flexible.

marek

Attachment: signature.asc
Description: Digital signature