> On Jul 31, 2014, at 10:01 AM, Byung-chul Hong <[email protected]> > wrote: > > Hello, > > I'm testing the scalability of memcached-1.4.20 version in a GET dominated > system. > For a linked-list traversal in a hash table (do_item_get), it is protected by > interleaved lock (per bucket), > so it showed very high scalability. > But, after linked-list traversal, LRU update is protected by a global lock > (cache_lock), > so the scalability was limited around 4~6 threads by global lock of the LRU > update global in a Xeon server system (10Gb ethernet).
The LRU fiddling only happens once a minute per item, so hot items don't affect the lock as much. The more you lean toward hot items the better it scales as-is. > > As i know, LRU is maintained per slab class, so LRU update modifies only the > items contained in the same class. > So, i think the global lock of LRU update may be changed to interleaved lock > per slab class. > By SET command at the same time, store and removal of items in the same class > can happen concurrently, > but SET operation also can be changed to get the slab class lock before > adding/removing some new items to/from the slab class. > > In case of store/removal of the "linked item" in the hash table (which may > reside on the different slab class), > it only updates the h_next value of current item, and it does not touch LRU > pointers (next, prev). > So, i think it would be safe to change to interleaved lock. > > Are there any other reasons that LRU update requires a global lock that I > missed ?? > (I'm not using slab rebalance and giving an initial hash power value large > enough, and clients only use GET, SET commands) I don't think anything stops it. Rebalance tends to stay within one class. It was on my list of scalability fixes to work on, but I postponed it for a few reasons. One is that most tend to have over half of their requests in one slab class. So splitting the lock doesn't give as much of a long term benefit. So, I wanted to come back to it later and see what other options were plausible for scaling the lru within a single slab class. Nobody's complained about the performance after the last round of work as well, so it stays low priority. Are your objects always only hit once per minute? What kind of performance are you seeing and what do you need to get out of it? > > It would be highly appreciated for any comments!! > > -- > > --- > 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. -- --- 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.
