-
Notifications
You must be signed in to change notification settings - Fork 442
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
fix(build): production flamegraphs are useless #6764
Conversation
Requesting review from @abhigets and @bayandin mostly to raise awareness. @jcsp might be generally interested in this, and @koivunej and @conradludgate are probably the best to judge whether my solution follows best practices with Cargo. |
e880432
to
aca8877
Compare
I have no thoughts or concerns about the flags here |
2436 tests run: 2318 passed, 0 failed, 118 skipped (full report)Code coverage (full report)
The comment gets automatically updated with the latest test results
aca8877 at 2024-02-14T18:13:22.591Z :recycle: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If android is using this, it should be safe for us as well. This is what I've been using locally, never tried to produce flamegraphs with production binaries.
Problem
Running a flamegraph on a pageserver build today yields a flamegraph with sort-of flattened stacks:
Analysis
We use
mold
to link the production binaries.It seems that, similar to when using
lld
, it's necessary to set--no-rosegment
, as is also recommended by theflamegraph-rs
tools.Setting it fixes the issue on my workstation.
I don't use
mold -run
there, but instead usemold
by setting defaultrustflags
in my~/.cargo/config.toml
:Solution For Production Binaries
Our production binaries are the ones built inside docker, see
./Dockerfile
.It would be nice if we could just make the setting once, somewhere inside
$checkout/Cargo.toml
or$checkout/.cargo/config.toml
.That way, all developers, _and the artifact builds, would automatically get the correct flags.
Sadly, the various ways to configure the rust compiler flags in cargo don't compose well.
I.e., there's a strict priority order and one replaces the other.
So, this PR sets the right rust compiler flags through the
RUSTFLAGS
env var, which is otherwise unset in the Dockerfile, so, we don't have to worry about losing any flag overrides.This PR also augments the README with a hint on how to get proper flamegraphs on developer builds.