[
https://issues.apache.org/jira/browse/DRILL-5270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16384080#comment-16384080
]
ASF GitHub Bot commented on DRILL-5270:
---------------------------------------
Github user kkhatua commented on the issue:
https://github.com/apache/drill/pull/755
The choice for a `TreeSet` is to basically use a binary structure that
keeps the (maximum permitted) profiles sorted and in memory.
When Drill detect changes,
(Refer
https://github.com/kkhatua/drill/blob/f7ad29b9a322bb215d16b3c3b9a2bfc40abfc1ed/exec/java-exec/src/main/java/org/apache/drill/exec/store/sys/store/LocalPersistentStore.java#L146)
it will fetch all the available profiles in the PStore and reconstruct the
tree (since the order of the profiles returned by the `FileSystem` is not
guaranteed).
I tried using the `PathFilter` to fetch only new profiles, but the cost of
the `FileSystem` fetching only new profiles, versus the entire list is the
same! Also, there is the possibility that some profiles might have been deleted
as new ones were added, so a full reconstruction would take care of that
scenario as well.
To evict, as I construct the TreeSet, I simply pop the oldest (by filename)
entry. The Guava cache options don't seem to provide a way to define the basis
on which to evict entries.
I believe, @vrozov's work on DRILL-6053 is to address locking during writes
specifically. The lock I used (and need) is for reads to ensure that multiple
requests don't trigger an expensive FileSystem call for the same state of the
PStore.
e.g. consider T# as timestamps
* `currBasePathModified` = T0
* _ThreadA_ requests at t=T1 and issues a read-lock
* _ThreadB_ requests at t=T2 but is waiting for read-lock
If the tree exists and no change is detected, _ThreadA_ will use the
`TreeSet` contents and resume by releasing the lock.
If the `TreeSet` exists and a change is detected, _ThreadA_ will
reconstruct the `TreeSet` before using its contents and it will update
`lastBasePathModified`, before releasing the lock.
When _ThreadB_ gets the read-lock, it discovers that during the wait, the
`TreeSet` was already updated. So, in terms of t=T2, this is the most recent
snapshot, so it proceeds to use the treeSet's contents rather than reconstruct.
That will be deferred to the next request.
We're using the `lastBasePathModified` as a way to provide a
pseudo-versioned access to the list. That means if there are more profiles
added *after* _ThreadB_ was waiting for the read-lock, it will not trigger the
`FileSystem` call right away.
> Improve loading of profiles listing in the WebUI
> ------------------------------------------------
>
> Key: DRILL-5270
> URL: https://issues.apache.org/jira/browse/DRILL-5270
> Project: Apache Drill
> Issue Type: Improvement
> Components: Web Server
> Affects Versions: 1.9.0
> Reporter: Kunal Khatua
> Assignee: Kunal Khatua
> Priority: Major
> Fix For: 1.14.0
>
>
> Currently, as the number of profiles increase, we reload the same list of
> profiles from the FS.
> An ideal improvement would be to detect if there are any new profiles and
> only reload from the disk then. Otherwise, a cached list is sufficient.
> For a directory of 280K profiles, the load time is close to 6 seconds on a 32
> core server. With the caching, we can get it down to as much as a few
> milliseconds.
> To render the cache as invalid, we inspect the last modified time of the
> directory to confirm whether a reload is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
