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).
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) 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.
