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 ( > [email protected] <javascript:>) (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 [email protected] <javascript:>. > > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
