accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (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 22:16:45 GMT

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

Josh Elser commented on ACCUMULO-3982:
--------------------------------------

bq. A quick investigation shows that doubles the data structure size overhead

Makes me a little nervous -- doesn't the size of the data structures here affect both servers
and clients? Granted, it's probably not a lot of memory total, but still makes me wonder.

At first glance, something like Java's ConcurrentSkipListMap makes sense to me (and wouldn't
require a lot of effort), but I haven't done enough reading yet to be sure there isn't something
better. I wonder how the common access patterns the locator impl uses would affect the overall
concurrency of the structure. For example, in the server-failure case, we would invalidate
the locations of all tablets for a server which would likely be spread across the entire structure
which would probably slow down as concurrency increases. Would being able to store the locations
for a tablet close to the other tablets hosted by the same server be noticeably beneficial?

bq. Adding and removing a million objects to both only takes ~5s.

What did that look like size-wise? ~260MB like you said? Or is that 2*260MB maintaining a
cache and a treemap?

> 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