lkml.org 
[lkml]   [2009]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [patch 016/104] epoll: introduce resource usage limits
    From
    On Sat, Jan 24, 2009 at 4:50 AM, Bron Gondwana <brong@fastmail.fm> 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" <gregkh@suse.de> 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:
    >
    > http://www.mail-archive.com/fedora-kernel-list@redhat.com/msg01618.html
    >
    > 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
    1.5M).

    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.


    Vegard

    --
    "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    [W:0.025 / U:0.484 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site