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.

Sign up for GitHub

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

restore: reduce allocations when restoring to longer tenant keys #120149

Merged
merged 1 commit into from
Mar 11, 2024
Merged

restore: reduce allocations when restoring to longer tenant keys #120149

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
23 changes: 22 additions & 1 deletion pkg/ccl/backupccl/key_rewriter.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,6 +94,9 @@ type KeyRewriter struct {
prefixes prefixRewriter
tenants prefixRewriter
descs map[descpb.ID]catalog.TableDescriptor
// alloc is used to amortize the cost of many small allocations for keys which
// change length during rewriting, preventing doing so in-place.
alloc []byte
}

// MakeKeyRewriterFromRekeys makes a KeyRewriter from Rekey protos.
Expand Down Expand Up @@ -273,7 +276,25 @@ func (kr *KeyRewriter) RewriteKey(
copy(keyTenantPrefix, newTenantPrefix)
rekeyed = append(keyTenantPrefix, rekeyed...)
} else {
rekeyed = append(newTenantPrefix, rekeyed...)
// Prefix length changed so we cannot rewrite it in-place; instead allocate
// the new key off the allocation slab, refilling it if needed first.
l := len(newTenantPrefix) + len(rekeyed)
Copy link
Collaborator

Choose a reason for hiding this comment

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

could you write a comment explaining why you're doing this? I believe the idea is that you want to reduce the number of times we allocate memory by allocating a slab of memory every time we exhaust our alloc buf.

Copy link
Collaborator

Choose a reason for hiding this comment

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

it also seems that we can use this strategy here too, though I think this path in traditional restore.

Copy link
Member Author

Choose a reason for hiding this comment

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

that we can use this strategy here too

We could. we'd need to hang the slab off the rule instead of the rewriter or something. I'm not very motivated until I see it in a profile, which would probably be from backing up table < 127 and restoring > 127.

Copy link
Member Author

Choose a reason for hiding this comment

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

added comments

if len(kr.alloc) < l {
// If individual keys are huge, allocate only 16 at a time, so that they
// can be freed sooner (aliasing) and one key doesn't massively over-alloc
// by a factor of 256. Otherwise allocate 256 worth so we don't need to
// do this again for awhile.
if l > 1<<20 {
kr.alloc = make([]byte, l*16)
} else {
kr.alloc = make([]byte, l*256)
}
}
tmp := kr.alloc[:l:l]
kr.alloc = kr.alloc[l:]
copy(tmp, newTenantPrefix)
copy(tmp[len(newTenantPrefix):], rekeyed)
rekeyed = tmp
}

return rekeyed, ok, err
Expand Down
Loading