HADOOP-19622: [ABFS][ReadAheadV2] Implement Read Buffer Manager V2 with improved aggressiveness #7832
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
| public static final int DEFAULT_READAHEAD_V2_MAX_BUFFER_POOL_SIZE = -1; | ||
| public static final int DEFAULT_READAHEAD_V2_EXECUTOR_SERVICE_TTL_MILLIS = 3_000; | ||
| public static final int DEFAULT_READAHEAD_V2_CPU_MONITORING_INTERVAL_MILLIS = 6_000; | ||
| public static final int DEFAULT_READAHEAD_V2_THREAD_POOL_UPSCALE_PERCENTAGE = 20; |
There was a problem hiding this comment.
For some variable you have used Persentage and for percent, we should keep it consistent across all places.
| public static final int DEFAULT_READAHEAD_V2_EXECUTOR_SERVICE_TTL_MILLIS = 3_000; | ||
| public static final int DEFAULT_READAHEAD_V2_CPU_MONITORING_INTERVAL_MILLIS = 6_000; | ||
| public static final int DEFAULT_READAHEAD_V2_THREAD_POOL_UPSCALE_PERCENTAGE = 20; | ||
| public static final int DEFAULT_READAHEAD_V2_THREAD_POOL_DOWNSCALE_PERCENTAGE = 30; |
| private static int threadPoolUpscalePercentage; | ||
| private static int threadPoolDownscalePercentage; | ||
| private static int executorServiceKeepAliveTimeInMilliSec; | ||
| private static final double THREAD_POOL_REQUIREMENT_BUFFER = 1.2; // 20% more threads than the queue size |
There was a problem hiding this comment.
Is this configurable? or we have fixed this number based on POC data? Is so can we explain about it little more for future understanding.
There was a problem hiding this comment.
This will only be used while upscaling. This is to make sure we have sufficient threads in thread pool to cater to all the queued buffer. This is just to understand if we need to upscale further or not. If we don't have enough queued requests we won't upscale even if cpu is much below threshhold.
The new thread pool size is still computed using configured vaues only.
| setReadAheadBlockSize(readAheadBlockSize); | ||
| } | ||
| private ReadBufferManagerV2() { | ||
| printTraceLog("Creating Read Buffer Manager V2 with HADOOP-18546 patch"); |
There was a problem hiding this comment.
We should use LOG.trace instead of printTraceLOG.
There was a problem hiding this comment.
Its same only. Just a method call to avoid redundant checks on log
| TimeUnit.MILLISECONDS); | ||
| } | ||
|
|
||
| printTraceLog("ReadBufferManagerV2 initialized with {} buffers and {} worker threads", |
There was a problem hiding this comment.
Same as above, please change it whereever you have used it.
There was a problem hiding this comment.
Its a intentional method created to avoid code redundancy
| return stream; | ||
| } | ||
|
|
||
| public String getETag() { |
There was a problem hiding this comment.
Read Buffers are created only during queueing . There we are setting it.
| // while waiting, so no one will be able to change any state. If this becomes more complex in the future, | ||
| // then the latch cane be removed and replaced with wait/notify whenever getInProgressList() is touched. | ||
| } catch (InterruptedException ex) { | ||
| Thread.currentThread().interrupt(); |
There was a problem hiding this comment.
In the catch block- we're interrupting the thread but not informing the caller. Is it expected?
There was a problem hiding this comment.
It will be thrown to caller.
| // getInProgressList(). So this latch is safe to be outside the synchronized block. | ||
| // Putting it in synchronized would result in a deadlock, since this thread would be holding the lock | ||
| // while waiting, so no one will be able to change any state. If this becomes more complex in the future, | ||
| // then the latch cane be removed and replaced with wait/notify whenever getInProgressList() is touched. |
| int cursor = (int) (position - buf.getOffset()); | ||
| int availableLengthInBuffer = buf.getLength() - cursor; | ||
| int lengthToCopy = Math.min(length, availableLengthInBuffer); | ||
| System.arraycopy(buf.getBuffer(), cursor, buffer, 0, lengthToCopy); |
There was a problem hiding this comment.
we can skip it for cases when lengthToCopy = 0
There was a problem hiding this comment.
For length 0 we won't even read.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
| LOG.debug("issuing read ahead requestedOffset = {} requested size {}", | ||
| nextOffset, nextSize); | ||
| readBufferManager.queueReadAhead(this, nextOffset, (int) nextSize, | ||
| getReadBufferManager().queueReadAhead(this, nextOffset, (int) nextSize, |
There was a problem hiding this comment.
Needs changes in constructor to return an instance of readbuffermanager v2 if enabled
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
… into RBMV2_HADOOP-19622
This comment was marked as outdated.
This comment was marked as outdated.
============================================================
|
|
💔 -1 overall
This message was automatically generated. |
Description of PR
JIRA: https://issues.apache.org/jira/browse/HADOOP-19622
Implementing ReadBufferManagerV2 as per the new design document.
Following capabilities are added to ReadBufferManager:
For more details on design doc please refer to the design doc attached to parent JIRA: https://issues.apache.org/jira/browse/HADOOP-19596
How was this patch tested?
TBA