You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
TableBucket reader requests reads up to 1MB from the Read Index because it does not know the length of the entry to be read. if the underlying index is not too fragmented (i.e., it has a 1MB cache entry), then that whole entry will be returned, copied and a slice from it will be returned to upstream code. However that slice still points to a 1MB buffer, even if it only needs 100 bytes out of it.
Concurrent reads from a Table Segment can easily overwhelm the heap memory if they run in this situation.
Expected behavior
Make a copy of the slice if necessary - this should cause only the necessary data to be held in memory.
Additionally, perhaps read only the header first and then figure out how much more to read. This may help solve the extra memory being read, but it will come with performance implications (multiple read requests). TBD: explore a good balance here.
Additional context
TableBucketReader and underlying classes.
The text was updated successfully, but these errors were encountered:
Cherry-picking these PRs:
#5841: Issue #5840: (SegmentStore) Fixed a deadlock in SegmentKeyCache.
#5851: Issue #5850: (SegmentStore) Fixed a bug in WriterTableProcessor where it would attempt to flush to a deleted segment.
#5586: Issue #5581: (SegmentStore) Disabling non-essential cache inserts if cache utilization is high
#5804: Issue #5789: (SegmentStore) Improving stability during Segment Container Recoveries
#5811: Issue #5810: (SegmentStore) Fixed a StorageWriter bug that could lead to data loss
#5783: Issue #5771: (SegmentStore) Reducing the amount of heap memory used when doing Table Segment Reads.
Signed-off-by: Andrei Paduroiu <andrei.paduroiu@emc.com>
Describe the bug
TableBucket reader requests reads up to 1MB from the Read Index because it does not know the length of the entry to be read. if the underlying index is not too fragmented (i.e., it has a 1MB cache entry), then that whole entry will be returned, copied and a slice from it will be returned to upstream code. However that slice still points to a 1MB buffer, even if it only needs 100 bytes out of it.
Concurrent reads from a Table Segment can easily overwhelm the heap memory if they run in this situation.
Expected behavior
Make a copy of the slice if necessary - this should cause only the necessary data to be held in memory.
Additionally, perhaps read only the header first and then figure out how much more to read. This may help solve the extra memory being read, but it will come with performance implications (multiple read requests). TBD: explore a good balance here.
Additional context
TableBucketReader and underlying classes.
The text was updated successfully, but these errors were encountered: