accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Newton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3982) Add LRU mechanism to address memory concerns and possibly pre-fetch Tablet Locations.
Date Mon, 31 Aug 2015 17:53:47 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723770#comment-14723770
] 

Eric Newton commented on ACCUMULO-3982:
---------------------------------------

Some points discussed with [~phrocker] off line:

# the tablet servers used to clear the Locator cache after finishing a bulk import request.
By switching to once-per-hour in ACCUMULO-3549, this is no longer true.
# at larger scales, even once per hour is aggressive.  Eventually you are re-reading the metadata
table every few seconds, for no reason
# the Locator needs more testing: for example, it always uses a single write lock to serialize
lookups, which is a bad behavior for random tablet lookups. Locator does some simple read-ahead.
Is it enough? Is it too much?
# a configurable size-limited LRU cache makes much more sense if the concern is memory usage
# TreeMap isn't exactly the most space-efficient store: [~kturner] thinks a 10-byte location
entry requires 256 bytes. However, caching a million tablets would only use 0.25G which is
not that much if you have a million-tablet Accumulo instance
# the main issue [~phrocker] was investigating is ACCUMULO-3835, which has already been fixed
in 1.8



> Add LRU mechanism to address memory concerns and possibly pre-fetch Tablet Locations.
> -------------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-3982
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3982
>             Project: Accumulo
>          Issue Type: New Feature
>          Components: client, tserver
>    Affects Versions: 1.6.3, 1.7.0, 1.8.0
>            Reporter: marco polo
>            Assignee: Eric Newton
>             Fix For: 1.8.0
>
>
> On larger systems, especially those of which may split frequently, I've seen churn in
the TabletLocator caches. Could we possibly pre-fetch entries for a table so that we don't
constantly access the metadata table for tablet locations. 
> Additionally, instead of clearing the cache in the case of a miss or failure, could we
simply update those entries in the cache? If we do this we may minimize cache misses overall
and the need to scan the meta data table. If need be, we could have a threshold before clearing
the cache entirely if people see the need for that.
> It would also be helpful to add an LRU cache ( or maybe even priority based LRU cache
). In ACCUMULO-3549, we added a cache clear to TabletServer to avoid overwhelming memory.
An LRU cache might address this concern and make the clear cache call unnecessary.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message