Addition, the libevent version is "1.4.14b-stable".
在 2014年10月29日星期三UTC+8下午3时01分43秒，Samdy Sun写道：
>
> Thanks for the reply.
> I'am absolutely sure the running version was 1.4.20. And I don't know how
> can this happen.
> Really, I use unix domain for running, and inet domain just for telnet
> easily.
>
>
> 在 2014年10月29日星期三UTC+8下午2时50分29秒，Dormando写道：
>>
>> You're absolutely sure the running version was 1.4.20? that looks like a
>> bug that was fixed in .19 or .20
>>
>> hmmm... maybe a unix domain bug?
>>
>> On Tue, 28 Oct 2014, Samdy Sun wrote:
>>
>> > Hello, I got a "memcached-1.4.20 stuck" problem when EMFILE happen.
>> > Here are my memcached's cmdline "memcached -s /xxx/mc_usock.11201 -c
>> 1024 -m 4000 -f 1.05 -o slab_automove -o slab_reassign -t 1 -p 11201".
>> >
>> > cat /proc/version
>> > Linux version 2.6.32-358.el6.x86_64 (
>> mock...@x86-022.build.eng.bos.redhat.com) (gcc version 4.4.7 20120313
>> (Red Hat 4.4.7-3) (GCC) ) #1 SMP Tue
>> > Jan 29 11:47:41 EST 2013
>> >
>> > memcached-1.4.20 stuck and don't work any more when it runs for
>> a period of time.
>> >
>> > Here are some information for gdb: (gdb) p stats
>> > $2 = {mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind
>> = 0, __nusers = 0, {__spins = 0,
>> > __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>,
>> __align = 0}, curr_items = 149156,
>> > total_items = 9876811, curr_bytes = 3712501870, curr_conns = 5,
>> total_conns = 39738, rejected_conns = 0,
>> > malloc_fails = 0, reserved_fds = 5, conn_structs = 1012, get_cmds =
>> 0, set_cmds = 0, touch_cmds = 0,
>> > get_hits = 0, get_misses = 0, touch_hits = 0, touch_misses = 0,
>> evictions = 0, reclaimed = 0,
>> > started = 0, accepting_conns = false, listen_disabled_num = 1,
>> hash_power_level = 17,
>> > hash_bytes = 524288, hash_is_expanding = false, expired_unfetched =
>> 0, evicted_unfetched = 0,
>> > slab_reassign_running = false, slabs_moved = 20, lru_crawler_running
>> = false,
>> > disable_write_by_exptime = 0, disable_write_by_length = 0,
>> disable_write_by_access = 0,
>> > evicted_write_reply_timeout_times = 0}
>> >
>> > (gdb) p allow_new_conns
>> > $4 = false
>> >
>> > And I found that "allow_new_conns" just set to false when "accept"
>> failed and errno is "EMFILE".
>> > Here are the codes:
>> > static void drive_machine(conn *c) {
>> > ……
>> > } else if (errno == EMFILE) {
>> > if (settings.verbose > 0)
>> > fprintf(stderr, "Too many open
>> connections\n");
>> > accept_new_conns(false);
>> > stop = true;
>> > } else {
>> > ……
>> > }
>> >
>> > If I change the flag "allow_new_conns", it can work again. As below:
>> > (gdb) set allow_new_conns=1
>> > (gdb) p allow_new_conns
>> > $5 = true
>> > (gdb) c
>> > Continuing.
>> >
>> > I know that "allow_new_conns" will be set to "true" when "conn_close"
>> called. But how could it happen for the case that when "accept" failed ,
>> > and errno is "EMFILE", and this connection is the only one for
>> accepting. Notes that curr_conns = 5.
>> > Not run out of fd:
>> > ls /proc/1748(memcached_pid)/fd | wc -l
>> > 17
>> >
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups "memcached" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to memcached+...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>
>
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
