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

[Libevent-users] Re: libevent2 stuck in Linux, CPU 100%



I can add that this problem happen after "too many open file descriptors" condition reached but it persists even after the sockets are cleaned.



On Fri, Jul 19, 2013 at 5:29 AM, Oleg Moskalenko <mom040267@xxxxxxxxx> wrote:
Hi

I am the author and developer of the rfc5766-turn-server project:

https://code.google.com/p/rfc5766-turn-server/

I have a strange problem with libevent2 consuming 100% of 100% of CPU in Linux (any linux) on high load condition, even after the load is back to normal. Basically, the system is doing nothing, just spinning inside libevent loop, indefinitely. The system is responsitive, but CPU is consumed 100%. When I connect to it with gdb, I always find myself somewhere inside timing functions in epoll loop, for example:

==================================

#0  0x00007f33e913a0d3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f33ea3b2f37 in ?? () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
#2  0x00007f33ea39ede4 in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5
#3  0x000000000040e1ec in run_events (eb=0x14ae060) at src/apps/relay/mainrelay.c:1006
#4  0x000000000040e2dd in run_listener_server (eb=0x14ae060) at src/apps/relay/mainrelay.c:1039
#5  0x0000000000410ebd in main (argc=0, argv=0x7fffffe549d8) at src/apps/relay/mainrelay.c:2457

=================================

everything works fine in other OS's (BSD, Solaris). But all Linuxes have this problem.

I was searching the Internet and I found the thread where people are having the exact same problem:

http://lists.pgfoundry.org/pipermail/pgbouncer-general/2011-May/000805.html

They resolved the problem by not using the libevent. Unfortunately, my system is built around libevent2 and I cannot afford that solution.

is there a known bug, and how do I deal with this problem ? Too many users are using Linux, I cannot tell everybody to switch to BSD.

Thanks
Oleg