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

cmd/load: reduce memory usage #4777

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jiefenghuang
Copy link
Contributor

close #4766

test:

  • meta: 31M total entries, biggest dir has 11M files
  • cost: loaded to badger with 14GiB memory
echo $((14 * 1024 * 1024 * 1024)) > /sys/fs/cgroup/memory/limited_mem_group/memory.limit_in_bytesq
sudo cgexec -g memory:limited_mem_group ./juicefs load badger://test.badger /data/code/com/juicedata/test/dump.json.gz

Signed-off-by: jiefenghuang <jiefeng@juicedata.io>
@jiefenghuang jiefenghuang marked this pull request as ready for review April 25, 2024 08:09
@@ -587,6 +596,11 @@ func decodeEntry(dec *json.Decoder, parent Ino, cs *DumpedCounters, parents map[
return nil, fmt.Errorf("decode %v: %s", name, err)
}
}
if decodeCounter >= gcThreshold || len(e.CompressedEntries) > gcThreshold {
decodeCounter = 0
runtime.GC()
Copy link
Contributor

@davies davies Apr 26, 2024

Choose a reason for hiding this comment

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

it's better to use mem pool for DumpedEntry and compressedAttr

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, mem pool can improve performance and reduce GC pressure.
However, testing shows that in this scenario, with 11M files in a single folder, if GC is not triggered in time, memory will still continue to grow, leading to OOM.

Copy link
Contributor

Choose a reason for hiding this comment

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

We don't need to over optimize for this single case.

btw, since we don't use JSON to serialize the whole tree directly, we can change type of Entries of DumpedEntry to slice of compressAttr.

Copy link
Contributor

Choose a reason for hiding this comment

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

btw, we can optmize this after 1.2

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't need to over optimize for this single case.

btw, since we don't use JSON to serialize the whole tree directly, we can change type of Entries of DumpedEntry to slice of compressAttr.

Entries map[string]*DumpedEntry json:"entries,omitempty"``
This variable is still necessary during the dump and load processes.

@jiefenghuang jiefenghuang marked this pull request as draft April 26, 2024 03:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

juicefs load cost too much memory and OOM.
2 participants