On 12/15/2016 11:44 AM, Igor Fedotov wrote:
On 15.12.2016 20:34, Mark Nelson wrote:
On 12/15/2016 11:24 AM, Igor Fedotov wrote:
Sage et al,
shouldn't we have bluestore_cache_metadata_ratio set to 1 by default? To
concentrate on metadata caching..
I would contend that it should be high (we've already bumped it up,
I'd go higher still), but isn't 1 a little excessive? Ultimately this
should all be automatic based on heuristics imho.
Well, Mark - what's the use case for user data caching? It means that
user either retrieves just written data or reads them repeatedly or in
an unaligned manner. Or there are multiple users working with the same
object.
Any of that is IMHO a corner case... That can be handled by using that
ratio setting if needed.
IMHO Onode caching is much more important and profitable than user data
one. It's rather a client misbehavior to cause cache hit when accessing
user data but it's highly expected for onode metadata.
We should take care not to run into the same problem the kernel does.
With too many cached entries things can get slow. It's another
trade-off we need to watch out for. There may need to be a (hopefully
automatically generated) soft limit, and potentially a hard limit.
Doesn't our cache size limit server that purpose?
I guess I'm thinking of this in the context that eventually we move away
from all of the user-defined cache/buffer/etc size limits. Maybe we
still have hard imposed maximum limits though, I'm not sure. I guess it
depends on whether we can make the autotuning smart enough and how
quickly we start hitting CPU limits with tons of entries in cache.
Mark
Moreover user data caching is probably already exists at block device
level hence we rather duplicate disk cache....
What do you think?
Thanks,
Igor
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
