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

Execution Log Sorting Causes Huge Memory Consumption when --execution_log_binary_file and --execution_log_json_file are enabled #17111

Closed
auzhva opened this issue Jan 2, 2023 · 4 comments
Labels
good first issue P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Performance Issues for Performance teams type: bug

Comments

@auzhva
Copy link

auzhva commented Jan 2, 2023

Description of the bug:

Both --execution_log_binary_file and --execution_log_json_file do execution log sorting. This requires Bazel to load the entire log into memory and if execution is big enough then it causes out of memory issues.

On real-life scenarios it's required to give up to --host_jvm_args=-Xmx64g just to let it sort a log.

While sorting may be useful for some scenarios, this is far from being necessary everywhere. For example, in our scenario execution log is needed only to understand how many non-cached actions were there and what are they. It's absolutely meaningless to spend all that memory to sort it.

I believe that sorting should be part of execution log comparison tools, not Bazel itself. Or at least Bazel should provide a way to opt-out from sorting for those for whom that is not needed.

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

  1. Run bazel build --execution_log_binary_file=log.bin //some/big/target
  2. See how it fails

Which operating system are you running Bazel on?

linux

What is the output of bazel info release?

release 6.0.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

Private repository

Have you found anything relevant by searching the web?

https://bazelbuild.slack.com/archives/CA31HN1T3/p1672037815196099

Any other information, logs, or outputs that you want to share?

No response

@auzhva
Copy link
Author

auzhva commented Jan 3, 2023

Hi,

It requires something big enough. So some "minimal sample" wouldn't trigger the memory issue. Needs something like 50k actions at least, so the execution log would be big enough (few Gbs at least), so when it will load it for sorting it would run out of memory.

Especially visible on builds with 100k+ actions.

I'll try to fund something open source of that size and/or generate some synthetic tree with no-op rule maybe if necessary... So far at the moment couldn't share corporate repo of that size.

@tjgq tjgq self-assigned this Jan 10, 2023
@tjgq
Copy link
Contributor

tjgq commented Jan 13, 2023

I can totally believe that one might run out of memory when sorting very large execution logs. I'd be willing to review a PR adding a flag to disable sorting, if someone were to send it.

@tjgq tjgq added good first issue P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed untriaged labels Jan 13, 2023
@tjgq tjgq removed their assignment Jan 13, 2023
@YuanHao97
Copy link
Contributor

@tjgq I opened a PR about this issue, could you help me review it?

ShreeM01 added a commit that referenced this issue Feb 16, 2023
This may improve performance when the execution log gets very large. The default is still to sort, so this is a backwards-compatible change.

Closes #17354.
Closes #17111.

PiperOrigin-RevId: 509822315
Change-Id: If948ec4a933389b6f8405985813dd76c549c445c

Co-authored-by: Hao Yuan <y1997h@126.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue P3 We're not considering working on this, but happy to review a PR. (No assignee) team-Performance Issues for Performance teams type: bug
Projects
None yet
4 participants
@auzhva @tjgq @YuanHao97 and others