Hi, just out of curiosity, what are those tracks? I was thinking as Jaime per slab class mutex and also static division of the hashtable with specific mutex for each part; am I in the right direction?
cheers, Jean-Charles On Jun 15, 9:11 am, Toru Maesaka <[email protected]> wrote: > Hi! > > Apologies for the late reply. > > Things you've mentioned are correct and we've talked about > SMP performance issues of the daemon for a while at hackathons, > events, IRC and etc. As Dustin had mentioned, some experimental > work has been done and hopefully things will look better in future > releases :) > > You know, things were worse prior to 1.4 with the global stats lock > so we've actually come quite far since 1.2 ;) > > Cheers, > Toru > > > > On Sat, Jun 13, 2009 at 2:32 AM, Jaime Medrano<[email protected]> wrote: > > > I have been doing a little lock profiling on memcached and I have > > found that cache_lock has a lot of contention in machines with more > > than 4 processors. > > > Mutex contention is very bad when using libevent because it means that > > all connections assigned to the thread that is waiting are frozen. > > > Is there any plan on improving that? > > > I think that instead of using a global mutex, locking could be done on > > a per bucket basis plus an additional lock for LRU list management. > > > Would you be interested on any work on that direction? > > > Regards, > > Jaime.
