> hi Dormando,
> we use version 1.4.15. So it would be first step to update. Thank you!
>
> >Does your memory usage continue to go up while the number of connections is 
> >stable, or do 
> >the number of connections slowly increase with memory usage? 
>
> I am doing history query now. But to be sure, do you mean "curr_connections" 
> to compare or "connection_structures" or "total_connections" (this one
> has HUGE value, see below)

curr_connections is the current number of connected clients.
connection_structure is something I forgot about: If that number goes
wacky that's a memory leak (but there's memory within the structures isn't
totalled up anywhere yet).
total_connections is ticked up every time a client connects. so a
connect/disconnect/connect ups it by 2.

I'm curious if your memory leaks as curr_connections grows, or if that
number is relatively static (going up and down with traffic levels) but
memory continually slowly increases.

Please let me know when you've tried 1.4.17 - and if it still leaks,
provide 'stats' output from that version. Thanks!

> here is the stats from one of the servers:
>
> stats
> STAT pid 10409
> STAT uptime 322887
> STAT time 1388427859
> STAT version 1.4.15
> STAT libevent 1.4.13-stable
> STAT pointer_size 64
> STAT rusage_user 230345.511159
> STAT rusage_system 354573.674608
> STAT curr_connections 4151
> STAT total_connections 1251550661
> STAT connection_structures 6655
> STAT reserved_fds 40
> STAT cmd_get 26733462674
> STAT cmd_set 291587557
> STAT cmd_flush 0
> STAT cmd_touch 0
> STAT get_hits 26157644553
> STAT get_misses 575818121
> STAT delete_misses 6433865116
> STAT delete_hits 91028651
> STAT incr_misses 0
> STAT incr_hits 0
> STAT decr_misses 0
> STAT decr_hits 0
> STAT cas_misses 0
> STAT cas_hits 28992
> STAT cas_badval 22
> STAT touch_hits 0
> STAT touch_misses 0
> STAT auth_cmds 0
> STAT auth_errors 0
> STAT bytes_read 7326099432348
> STAT bytes_written 31415635467012
> STAT limit_maxbytes 25769803776
> STAT accepting_conns 1
> STAT listen_disabled_num 0
> STAT threads 8
> STAT conn_yields 0
> STAT hash_power_level 25
> STAT hash_bytes 268435456
> STAT hash_is_expanding 0
> STAT slab_reassign_running 0
> STAT slabs_moved 0
> STAT bytes 22814358539
> STAT curr_items 34689744
> STAT total_items 291584654
> STAT expired_unfetched 27821
> STAT evicted_unfetched 91912345
> STAT evictions 135352494
> STAT reclaimed 34495
>
> -Den
>
> On Friday, December 27, 2013 5:14:16 PM UTC-8, Dormando wrote:
>       > Hi everybody,What would be best practice to set max connections? We 
> have "memory leak" issue (memory usage grows, eats all available
>       memory,
>       > process crashes). I use quotes as I am not sure that this is actually 
> memory leak. I still thinking on the way to validate this. One
>       potential
>       > suspect is memory used for network connections. We have -c 128000. 
> And -m 24576 as memory limiter. the box itself has 48G of memory
>       and dedicated
>       > to memcache.
>       >
>       > Also, more abstract question: is there any way to see how memcache 
> uses memory? like what amount was reserved for connections?
>       >
>       > Thank you and Happy Holidays,
>       > Den
>
>       Hi!
>
>       What version are you running? If it's not 1.4.17, can you try that 
> version
>       and see if it still "leaks"? There was at least one bug fix in the last
>       two versions which could drop a connection structure.
>
>       The "stats" output can tell you how much memory is dictated for the slab
>       cache and for the hash table, but not all types of memory are accounted
>       presently.
>
>       That is a very large number of connections though. Can you provide some
>       'stats' output? How many connections do you usually have? Does your 
> memory
>       usage continue to go up while the number of connections is stable, or do
>       the number of connections slowly increase with memory usage?
>
> --
>  
> ---
> 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/groups/opt_out.
>
>

-- 

--- 
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/groups/opt_out.

Reply via email to