[lkml]   [2009]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 016/104] epoll: introduce resource usage limits
On Sat, Jan 24, 2009 at 4:50 AM, Bron Gondwana <> wrote:
> On Fri, Jan 23, 2009 at 09:06:31AM -0800, Greg KH wrote:
>> On Fri, Jan 23, 2009 at 08:47:45PM +1100, Bron Gondwana wrote:
>> > On Thu, 22 Jan 2009 21:16 -0800, "Greg KH" <> wrote:
>> > >
>> > > I would suggest just changing this default value then, it's a simple
>> > > userspace configuration item, and for your boxes, it sounds like a
>> > > larger value would be more suitable.
> If everyone, or every distribution at least, has to change it then the
> default is probably wrong. The error message in the postfix logs didn't
> immediately point me at the issue, especially since I tried debugging on
> one of our "production" mxes, only to discover that the epoll limit
> didn't exist there. They're slightly behind in kernel versions.
>> > I guess Postfix is a bit of an odd case here. It runs lots of
>> > processes, yet uses epoll within many of them as well - sort of
>> > a historical design in some ways, but also to enforce maximum
>> > privilege separation with many of the daemons able to
>> > be run under chroot with limited capabilities.
>> >
>> > So I guess I have a few questions left:
>> >
>> > 1) is this value ever supposed to be hit in practice by
>> > non-malicious software? If not, it appears 128 is too low.
>> It does appear a bit low. What looks to you like a good value to use as
>> a default?
> This thread suggests that it's not just postfix having the issue, and
> offers 1024 as a saner default:
> There's also a Russian thread that pointed me at this patch in the first
> place, and another place that suggested 1024 as well. Seems "the
> cloud"[tm] is converging on 1024.

With the default limit of 128 (max_user_instances) and 274274
(max_user_watches) on my machine, the maximum amount of memory
consumed by one user's epoll instances is barely noticable (around

Raising the max_user_instances to 512 brings us up to a maximum memory
usage of 43M already. However, from here on, we are already getting
limited by the number of user watches.


"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036

 \ /
  Last update: 2009-01-24 09:39    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean