<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 8:16 PM, Michael Barton <span dir="ltr"><<a href="mailto:mike@weirdlooking.com" target="_blank">mike@weirdlooking.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><div>What's the logical difference between having object data in memory on a memcache server and having it in page cache on an object server? </div></div></div></div></div></blockquote><div><br></div><div>+1 - about a syscall - i.e. not much - I think memcache does it's own heap management - so it's probably all userspace - but the locality is all wrong - just do it on the object nodes [1]!</div><div><br></div><div>... if you want object data served from memory - just turn on keep_cache_private and crank up keep_cache_size [2]</div>







<div><br></div><div>-Clay</div><div><br></div><div>1. concurrent GETs would help serve the warmed copies first - <a href="https://review.openstack.org/#/c/117710/">https://review.openstack.org/#/c/117710/</a></div><div>2. mind your /proc/fs/xfs/stat graphs tho - maybe not an issue if your object data filesystem is on an SSD storage policy tho</div></div></div></div>