Re: [Libevent-users] Problem with epoll in Centos 5.9/6.4?

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Tue, Oct 1, 2013 at 9:56 PM, Alex Agranovsky <alex@xxxxxxxxx> wrote:
> Are there known problems with either libevent or epoll mechanism in
> RHEL/Centos 5.9/6.4?
>
> We have a stable integration with libevent (using epoll), that had been
> running trouble-free for a few years. With some systems being upgraded to
> Centos 5.9, we've noticed that every once in awhile a server socket receives
> a notification about incoming connection, the connection is accept()'ed and
> added to base event via event_new/event_add -- and never receives any
> further notifications, neither for incoming data, nor for the far end
> dropping the connection.
>
> Packet capture shows both events (data incoming/connection closed)
> occurring. The following facts make me wonder if there's a problem:
> - as I've mentioned, the code ran trouble free, and under significant loads
> for a couple of years at least
> - neither libevent version, nor our code on top of it have changed
> - Centos 5.9 release notes mention a change in the affected area
> (https://bugzilla.redhat.com/show_bug.cgi?id=681578)
> - if we allocate enough base events to lighten the load on each, the problem
> goes away (we see the problem at about 60-70 sockets per base event; at
> about 30 it seems to never occur)
>
> Have you seen anything similar? Is there a limit on how many sockets can be
> added to a single base event?

There shouldn't be; I don't think there is. 70 sockets is a very low
limit; in practice, tens of thousands should work fine.

I'm not aware of a centos-specific issue here; does anybody else know
of one? If you have some way to reproduce this, looking at the strace
output from the running program to see the exact pattern of epoll and
related syscalls might shed some light on what exactly is going wrong
where, but it might need some work to postprocess.

-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.