RE: Global Lock When Getting Stats?
memcached.org/wiki also inside the source tarball there's a "protocol.txt" that explains the raw stats thoroughly. You seem to be referring to the php api's stats call. On Mon, 17 May 2010, Tim Sneed wrote: > Great thanks for the information! Is there any documentation available from > the project team that explains the monitoring aspects of memcached? Such as > the methods of receiving stats (if there are any aside from getStats())? > > > -Original Message- > From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On > Behalf Of dormando > Sent: Thursday, May 13, 2010 4:57 PM > To: memcached > Subject: Re: Global Lock When Getting Stats? > > > I was watching a Memcached video spoken by John Adams when I heard > > something that made me curious. When one gets stats from memcached, > > does it really perform a global lock? Does anyone have any good test > > cases on what sort of impact there is with an increasing node size > > with respect to performance degradation? > > 'stats sizes' grabs a global lock and iterates the whole cache. we don't > recommend you run that one. All other stats commands are extremely fast. > > > I am looking to do some research on expanding our product to support > > real-time monitoring, management, and analysis of memcached. But I'm a > > little concerned that this lock occurs during every stat collection, > > so much to the point that John Adams mentions that it can noticeably > > degrade the performance of memcached. I tried to do some research on > > my own but am finding very little performance analysis or any > > benchmark info with respect to constant polling (minimally 30 sec > > interval) of a enterprise-level memcached distributed system. Has > > anyone seen bad performance with respect to a large cluster and > > gathering stats? Any info would be great, thanks! > > There is no major lock every stat collection. There's a minor lock and > reading the values is very fast. > > A while ago twitter was running an extremely old version of memcached and > they took a long time to upgrade. That particular version had a bug in > stats collection that was *missing* a mutex lock, and would thus crash > sometimes. So they were afraid of running stats commands. That bug hasn't > existed for three years at least. > > -Dormando > >
Re: Sample C code for beginner
memcached_return_t
memcached_increment_with_initial (memcached_st *ptr,
const char *key,
size_t key_length,
uint64_t offset,
uint64_t initial,
time_t expiration,
uint64_t *value);
On May 17, 8:23 am, ram wrote:
> I am an absolute beginner with memcached & libmemcached ( a perl
> programmer by profession)
> I am trying to write a simple c code that will do the foll algorithm
>
>
> n = search_value_from_memcache(username);
> if(n) {
> increment_value_memcache(username)} else {
>
> set_value_memcache(username,1);}
>
> ---
>
> I am trying functions fromhttp://docs.tangent.org/libmemcached/index.html
>
> but I couldnt functions simple enough to just get & put
Sample C code for beginner
I am an absolute beginner with memcached & libmemcached ( a perl
programmer by profession)
I am trying to write a simple c code that will do the foll algorithm
n = search_value_from_memcache(username);
if(n) {
increment_value_memcache(username)
} else {
set_value_memcache(username,1);
}
---
I am trying functions from
http://docs.tangent.org/libmemcached/index.html
but I couldnt functions simple enough to just get & put
RE: Global Lock When Getting Stats?
Yes people do seem to like memcached, I've been seeing a lot of activity lately around it. Thank for you the in-depth explanation. I need to tinker with memcached some more before I have other questions, but I appreciate the prompt response! -ts -Original Message- From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On Behalf Of Trond Norbye Sent: Thursday, May 13, 2010 5:15 PM To: memcached@googlegroups.com Subject: Re: Global Lock When Getting Stats? On 13. mai 2010, at 22.46, Tim Sneed wrote: > I was watching a Memcached video spoken by John Adams when I heard > something that made me curious. When one gets stats from memcached, > does it really perform a global lock? Does anyone have any good test > cases on what sort of impact there is with an increasing node size > with respect to performance degradation? > > I am looking to do some research on expanding our product to support > real-time monitoring, management, and analysis of memcached. But I'm a > little concerned that this lock occurs during every stat collection, > so much to the point that John Adams mentions that it can noticeably > degrade the performance of memcached. I tried to do some research on > my own but am finding very little performance analysis or any > benchmark info with respect to constant polling (minimally 30 sec > interval) of a enterprise-level memcached distributed system. Has > anyone seen bad performance with respect to a large cluster and > gathering stats? Any info would be great, thanks! > First of all: I've never been able to see any kind of contention on the stats mutex in the new releases of memcached. There is actually multiple mutexes in used for stats: 1 per thread to collect information on a per thread basis (command counters etc), and one "global" for the things we haven't moved into a threadlocal counter yet. Every time a thread wants to increment a counter it will lock it's own mutex and increment the counter before unlocking it. In 99.999 % of the times no one else will access the mutex, so the operation shouldn't be _that_ expensive. We could probably live without the mutex, but we wanted to "be on the safe side" and use mutexes now (and come up with a better idea if it turned out to be a problem). Every time you run the stats command we will run through all the threads and lock their stats mutex and aggregate the counters before returning the values back to the user. If you're scared about global locking I can tell you that memcached actually use one mutex to ensure that only one thread accesses the internal hash table at the time, and that is used by all get/add/set/replace/append/prepend/del commands And people seems to like memcached anyway ;-) Cheers, Trond
RE: Global Lock When Getting Stats?
Great thanks for the information! Is there any documentation available from the project team that explains the monitoring aspects of memcached? Such as the methods of receiving stats (if there are any aside from getStats())? -Original Message- From: memcached@googlegroups.com [mailto:memcac...@googlegroups.com] On Behalf Of dormando Sent: Thursday, May 13, 2010 4:57 PM To: memcached Subject: Re: Global Lock When Getting Stats? > I was watching a Memcached video spoken by John Adams when I heard > something that made me curious. When one gets stats from memcached, > does it really perform a global lock? Does anyone have any good test > cases on what sort of impact there is with an increasing node size > with respect to performance degradation? 'stats sizes' grabs a global lock and iterates the whole cache. we don't recommend you run that one. All other stats commands are extremely fast. > I am looking to do some research on expanding our product to support > real-time monitoring, management, and analysis of memcached. But I'm a > little concerned that this lock occurs during every stat collection, > so much to the point that John Adams mentions that it can noticeably > degrade the performance of memcached. I tried to do some research on > my own but am finding very little performance analysis or any > benchmark info with respect to constant polling (minimally 30 sec > interval) of a enterprise-level memcached distributed system. Has > anyone seen bad performance with respect to a large cluster and > gathering stats? Any info would be great, thanks! There is no major lock every stat collection. There's a minor lock and reading the values is very fast. A while ago twitter was running an extremely old version of memcached and they took a long time to upgrade. That particular version had a bug in stats collection that was *missing* a mutex lock, and would thus crash sometimes. So they were afraid of running stats commands. That bug hasn't existed for three years at least. -Dormando
