Re: 1000-directory limit for svscan

Thanks all for responses so far.. FWIW, so far in 1000+ usage I'm not  
seeing any real performance issues.  One thing that is standing out  
is that there appear to be 14 or so open files for each supervise  
process, so those build up fast..


On 25-Mar-06, at 2:55 PM, Matthew R. Dempsky wrote:

> On Sat, Mar 25, 2006 at 01:44:49PM -0800, Andrew Catton wrote:
>> Does anyone know the reason for this hardcoded limit in svscan?
>> We're working with a fairly unusual deployment approach which
>> requires us to exceed it.  I've increased the SERVICES size, but
>> would like to know if I'm walking into some trouble that the limit
>> was meant to prevent..
>
> It looks like svscan uses an O(n^2) algorithm in how many services
> you're running.  If you're using a large number of services, you might
> consider splitting your services into multiple /service directories
> (e.g. /service1, /service2, ...) and running svscan on each of them.
>
> Also, I believe runit, Gerrit Pape's daemontools clone package,  
> will not
> rescan the /service directory if its mtime has not changed, so that
> might be another useful optimization if the services you are  
> managing do
> not change often.
>
> (Disclaimer: I'm just speculating.  I only manage about 20 services  
> with
> runit, so I've not had to look into benchmarking these  
> possibilities too
> extensively.  :-)