-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always use CacheService for caching metadata blobs #70668
Conversation
Pinging @elastic/es-distributed (Team:Distributed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change makes sense to me. I've done a first pass and left some comments.
|
||
@Override | ||
protected void doReadInternal(ByteBuffer b) throws IOException { | ||
final long position = getAbsolutePosition(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should compute the absolute and the relative positions only once here and pass them along as parameters to all other read methods which will be able to use whatever position they want but in a more explicit manner (ie relativePosition + b.remaining()
for example).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've addressed the other comments here, but I'm not yet sure how to go about this one. I've pushed aaa69e6 which removes the virtual file logic from FrozenCacheService and which simplifies things a bit further when it comes to position calculations (same for FrozenIndexInput as well as CachedBlobContainerIndexInput now).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's keep it as it is. I'll give it a try.
...e-snapshots/src/main/java/org/elasticsearch/index/store/cache/MetadataCachingIndexInput.java
Outdated
Show resolved
Hide resolved
...e-snapshots/src/main/java/org/elasticsearch/index/store/cache/MetadataCachingIndexInput.java
Outdated
Show resolved
Hide resolved
...e-snapshots/src/main/java/org/elasticsearch/index/store/cache/MetadataCachingIndexInput.java
Outdated
Show resolved
Hide resolved
@@ -83,13 +57,13 @@ public FrozenIndexInput( | |||
0L, | |||
0L, | |||
fileInfo.length(), | |||
new CacheFileReference(directory, fileInfo.physicalName(), fileInfo.length()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit torn on the file's length that is passed here. It means that we'll create a potentially large file in the cache service (and cause potential evictions) while we know it will only be used to cache at most directory.getBlobCacheByteRange(name, fileInfo.length()).length()
bytes. We could maybe affine this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that CacheService is always supposed to be unbounded (and that's how it should be, the goal is to remove the undocumented setting to even make this configurable, and remove the complexity around that)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I forgot about that point. Also my suggestion was pretty bad since the file length here passed to the sparse file tracker and that would just break things. Sorry for the noise.
@elasticmachine run elasticsearch-ci/2 (timeout downloading stuff from the internet) |
Relates to elastic#70763 and can be unmuted when elastic#70668 is unmuted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - I've left only minor things along the review, feel free to apply or ignore
TrackingRepositoryPlugin tracker = null; | ||
for (RepositoryPlugin plugin : getInstanceFromNode(PluginsService.class).filterPlugins(RepositoryPlugin.class)) { | ||
if (plugin instanceof TrackingRepositoryPlugin) { | ||
tracker = ((TrackingRepositoryPlugin) plugin); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: return here directly
@@ -33,6 +34,7 @@ | |||
import static org.elasticsearch.test.hamcrest.ElasticsearchAssertions.assertAcked; | |||
import static org.hamcrest.Matchers.containsString; | |||
|
|||
@ESIntegTestCase.ClusterScope(scope = ESIntegTestCase.Scope.TEST) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a single test in this class, why changing the scope to TEST?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's because when you run the test with tests.iters=x
, it will reuse the same node, and that breaks the test (RestoreBlockingActionFilter.executed and unblocked are not reset)
@@ -83,13 +57,13 @@ public FrozenIndexInput( | |||
0L, | |||
0L, | |||
fileInfo.length(), | |||
new CacheFileReference(directory, fileInfo.physicalName(), fileInfo.length()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I forgot about that point. Also my suggestion was pretty bad since the file length here passed to the sparse file tracker and that would just break things. Sorry for the noise.
...searchable-snapshots/src/main/java/org/elasticsearch/index/store/cache/FrozenIndexInput.java
Show resolved
Hide resolved
...searchable-snapshots/src/main/java/org/elasticsearch/index/store/cache/FrozenIndexInput.java
Outdated
Show resolved
Hide resolved
long bytesWritten = positionalWrite(fc, fileChannelPos + bytesCopied, buf); | ||
bytesCopied += bytesWritten; | ||
bytesCopied += (bytesWritten - adjustment); // adjust to not break RangeFileTracker |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the stats should show the exact bytes copied (ie we can confirm the 4K alignment) but progress updater got updated with the adjusted bytes copied?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will defer that to a follow-up as it will break a lot of tests (again)
|
||
@Override | ||
protected void doReadInternal(ByteBuffer b) throws IOException { | ||
final long position = getAbsolutePosition(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's keep it as it is. I'll give it a try.
This PR unifies CachedBlobContainerIndexInput and FrozenIndexInput so that they share the same infrastructure for caching metadata blobs as well as header and footer ranges for data blobs. The idea is to always use CacheService for this, which does not evict the metadata, and which efficiently stores the information on disk (using sparse file support). This also allows us to align writes in FrozenCacheService to 4KB block sizes in this PR, which addresses an issue when reusing regions from the shared cache, as writes that are not aligned on page cache boundaries causes the existing data (which we don't care about) to be loaded from disk, which comes with a dramatic performance penalty. Closes elastic#70728 Closes elastic#70763
This PR unifies CachedBlobContainerIndexInput and FrozenIndexInput so that they share the same infrastructure for caching metadata blobs as well as header and footer ranges for data blobs. The idea is to always use CacheService for this, which does not evict the metadata, and which efficiently stores the information on disk (using sparse file support). This also allows us to align writes in FrozenCacheService to 4KB block sizes in this PR, which addresses an issue when reusing regions from the shared cache, as writes that are not aligned on page cache boundaries causes the existing data (which we don't care about) to be loaded from disk, which comes with a dramatic performance penalty. Closes #70728 Closes #70763
…lastic#70795) This PR unifies CachedBlobContainerIndexInput and FrozenIndexInput so that they share the same infrastructure for caching metadata blobs as well as header and footer ranges for data blobs. The idea is to always use CacheService for this, which does not evict the metadata, and which efficiently stores the information on disk (using sparse file support). This also allows us to align writes in FrozenCacheService to 4KB block sizes in this PR, which addresses an issue when reusing regions from the shared cache, as writes that are not aligned on page cache boundaries causes the existing data (which we don't care about) to be loaded from disk, which comes with a dramatic performance penalty. Closes elastic#70728 Closes elastic#70763
This PR unifies CachedBlobContainerIndexInput and FrozenIndexInput so that they share the same infrastructure for caching metadata blobs as well as header and footer ranges for data blobs. The idea is to always use CacheService for this, which does not evict the metadata, and which efficiently stores the information on disk (using sparse file support).
This also allows us to align writes in FrozenCacheService to 4KB block sizes in this PR, which addresses an issue when reusing regions from the shared cache, as writes that are not aligned on page cache boundaries causes the existing data (which we don't care about) to be loaded from disk, which comes with a dramatic performance penalty.
In a follow-up, we should also add a test / bootstrap check that ensures that sparse file support is always provided.
Closes #70728
Closes #70763