Good guess. But we don't use IPTables. -Soham
On Jan 18, 10:53 pm, Todd Lipcon <[email protected]> wrote: > Any chance you're running iptables on that box? If so, perhaps your > ip_conntrack table is filling up. > > -Todd > > On Sat, Jan 17, 2009 at 8:21 PM, Soham <[email protected]> wrote: > > > After it has been up for 3+ hours, here are the stats. The number of > > connections is now steady at 62. > > > stats > > STAT pid 2580 > > STAT uptime 11216 > > STAT time 1232241574 > > STAT version 1.2.5 > > STAT pointer_size 64 > > STAT rusage_user 0.109983 > > STAT rusage_system 1.271806 > > STAT curr_items 99 > > STAT total_items 396 > > STAT bytes 671471 > > STAT curr_connections 62 > > STAT total_connections 67 > > STAT connection_structures 63 > > STAT cmd_get 56925 > > STAT cmd_set 396 > > STAT get_hits 55963 > > STAT get_misses 962 > > STAT evictions 0 > > STAT bytes_read 4601309 > > STAT bytes_written 376992355 > > STAT limit_maxbytes 1073741824 > > STAT threads 1 > > END > > > On Jan 17, 1:43 pm, Soham <[email protected]> wrote: > > > Well, even the very first connection after restart displays same > > > pattern of delays. So I'd think it is not too many connections. Also > > > we do not specify anything for -c (concurrent conn), which should > > > default to 1024, which is plenty. > > > > We do see connections slowly piling up though, as if the client does > > > not close them, which may be related. > > > > On Jan 17, 2:08 am, Marko Kevac <[email protected]> wrote: > > > > > On Jan 17, 1:01 am, Soham <[email protected]> wrote: > > > > > > 3) Start memcached on command line (not daemon) with -vv and watch > > the > > > > > logs:- No improvement. It does look like the delay is in making the > > > > > connection though, and not in fetching the object. > > > > > Too many connections opened?
