[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC] Increase default ulimit nofile

> > Now. This might be great for a honking great shared UNIX server from the
> > days of yore, but it's not remotely appropriate for a modern desktop.
> > Especially not one layered with so many per-user daemons and layers of
> > abstraction as we have on modern Linux systems.
> Well, one of the design points of DBus is that you only have a total
> of one file descriptor for normal processes to do most IPC to others,
> routed via the message bus; as opposed to say ORBit where it scales as
> O(N).  So adding more daemons and components shouldn't normally equate
> to more file descriptors.
> In other words agree with Lennart that it likely makes more sense to
> find this specific bug rather than globally increase the limit, in the
> absence of other examples at least.

Well, I've certainly had to bump it up to 8192 on several of the
machines I run.  The short version is we have a data aquisition system
which records many timestreams of data.  For ease of processing (and
display of subsets of the data) we save each raw timestream as an
individual file (using the getdata library,
http://getdata.sourceforge.net/).  We sometimes have run into the 1024
limit on the project I work on, and some of the projects my collegues
work on always run into this (having a few thousand timestreams to
record concurently).  

Obviously any file-descriptor leak should be fixed, but there are cases
where a couple thousand files need to be opened simultaneously.  

"If you drop your keys into a river of molten lava, forget about them, they're gone!"
Matthew Truch
Department of Physics and Astronomy
University of Pennsylvania
matt truch net

Attachment: pgp6JAiQcU0bx.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]