Skip to content
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

[#1472][part-2] fix(server): Reuse ByteBuf when decoding shuffle blocks instead of reallocating it #1521

Merged
merged 1 commit into from
Feb 15, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,6 @@
import org.apache.uniffle.common.ShuffleBlockInfo;
import org.apache.uniffle.common.ShuffleServerInfo;
import org.apache.uniffle.common.util.ByteBufUtils;
import org.apache.uniffle.common.util.NettyUtils;

public class Decoders {
public static ShuffleServerInfo decodeShuffleServerInfo(ByteBuf byteBuf) {
Expand All @@ -47,8 +46,7 @@ public static ShuffleBlockInfo decodeShuffleBlockInfo(ByteBuf byteBuf) {
long crc = byteBuf.readLong();
long taskAttemptId = byteBuf.readLong();
int dataLength = byteBuf.readInt();
ByteBuf data = NettyUtils.getNettyBufferAllocator().directBuffer(dataLength);
data.writeBytes(byteBuf, dataLength);
ByteBuf data = byteBuf.retain().readSlice(dataLength);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will byteBuf be spitted into muliple parts? Every part will released multiple times? Will it bring errors?

Copy link
Contributor Author

@rickyma rickyma Feb 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ByteBuf will not be splitted into multiple parts. It will be used by a SendShuffleDataRequest as a whole.
It will not bring errors. Because we retain the ByteBuf(refCnf++) everytime when we do a readSlice.

public static SendShuffleDataRequest decode(ByteBuf byteBuf) {
    long requestId = byteBuf.readLong();
    String appId = ByteBufUtils.readLengthAndString(byteBuf);
    int shuffleId = byteBuf.readInt();
    long requireId = byteBuf.readLong();
    Map<Integer, List<ShuffleBlockInfo>> partitionToBlocks = decodePartitionData(byteBuf);
    long timestamp = byteBuf.readLong();
    return new SendShuffleDataRequest(
        requestId, appId, shuffleId, requireId, partitionToBlocks, timestamp);
  }

But it might slow down the flushing process.
Because it will not trigger the actual flushing process util all the ShufflePartitionedData is flushed(refCnt decreased to 0):

List<ShufflePartitionedData> shufflePartitionedData = toPartitionedData(sendShuffleDataRequest);
...
for (ShufflePartitionedData spd : shufflePartitionedData) {
    ...
    ret = manager.cacheShuffleData(appId, shuffleId, isPreAllocated, spd);
    ...
}

ByteBuf cannot be splitted, once splitted we have to allocate new ByteBufs.
So maybe we can hold this PR and find a better way to do this.
But it will speed up the decoding process on the other hand.

int lengthOfShuffleServers = byteBuf.readInt();
List<ShuffleServerInfo> serverInfos = Lists.newArrayList();
for (int k = 0; k < lengthOfShuffleServers; k++) {
Expand Down
Loading