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

fix(build): production flamegraphs are useless #6764

Merged
merged 2 commits into from
Feb 16, 2024
Merged

Conversation

problame
Copy link
Contributor

@problame problame commented Feb 14, 2024

Problem

Running a flamegraph on a pageserver build today yields a flamegraph with sort-of flattened stacks:

before (current release builds)

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 the flamegraph-rs tools.

Setting it fixes the issue on my workstation.
I don't use mold -run there, but instead use mold by setting default rustflags in my ~/.cargo/config.toml:

# repeat / adjust for your target arch
[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/usr/local/bin/mold", "-Clink-arg=-Wl,--no-rosegment"]

after

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 theRUSTFLAGS 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.

@problame
Copy link
Contributor Author

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.

@problame problame force-pushed the problame/fix-flamegraphs branch from e880432 to aca8877 Compare February 14, 2024 17:25
@problame problame marked this pull request as ready for review February 14, 2024 17:25
@conradludgate
Copy link
Contributor

I have no thoughts or concerns about the flags here

Copy link

2436 tests run: 2318 passed, 0 failed, 118 skipped (full report)


Flaky tests (3)

Postgres 16

Postgres 15

  • test_crafted_wal_end[last_wal_record_crossing_segment]: debug
  • test_timeline_deletion_with_files_stuck_in_upload_queue: debug

Code coverage (full report)

  • functions: 56.0% (12860 of 22974 functions)
  • lines: 82.6% (69522 of 84170 lines)

The comment gets automatically updated with the latest test results
aca8877 at 2024-02-14T18:13:22.591Z :recycle:

Dockerfile Show resolved Hide resolved
Copy link
Member

@koivunej koivunej left a 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.

@problame problame merged commit 568bc1f into main Feb 16, 2024
50 checks passed
@problame problame deleted the problame/fix-flamegraphs branch February 16, 2024 10:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants