feat: add pprof api

[BaldDemian]

Rationale

Close #1577

Detailed Changes

• In src/server/src/http.rs, register the pprof api, similar to the existing /debug/profile/heap/{seconds}.
• In src/components/profile/src/lib.rs, implement dump_heap_pprof function, similar to the existing dump_heap_prof.

Test Plan

Manual test. More details are given below.

[BaldDemian]

how to test

1. In shell 1, build and run the HoraeDB server with heap profiling enabled:

   cargo build
   export MALLOC_CONF="prof:true,prof_active:false,lg_prof_sample:19"
   ./target/debug/horaedb-server --config docs/minimal.toml

2. In shell 2, run

   curl localhost:5440/debug/pprof/heap/15 > heap.pb.gz

3. Install pprof and Graphviz. You can generate report files(txt, svg...) using the pprof command and the heap.pb.gz file. Generally, running pprof commands in machines other than the original HoraeDB machine may see symbolization faiure like this:

   

   It says there are two missing directories:

   • ./target/debug/horaedb-server, the executable binary Rust code
   • /lib/x86_64-linux-gnu/libc.so, the Linux specific libc code

   The reason is that the original heap.pb.gz file only contains the addresses of the called functios instead of their names. pprof relies on the above two missing directories to map the function addresses to their names.

   It is worth mentioning that the symbolize feature is enabled in the jemalloc_pprof dependency, so the output heap.pb.gz file already contains all Rust functions names.

   In theory, maybe we can run pprof in other machines of the exact the same (otherwise the libc code may be different ) OS version of the HoraeDB machine, without seeing above symbolization faiure.

   But on other OSes, the failure still exists since they don't contain the correct /lib/x86_64-linux-gnu/libc.so file. For example, on my arm64 macOS machine, it shows:

   

   But you can still see that the Rust funtion names are shown, due to the enabled symbolize feature in the jemalloc_pprof dependency. This feature may slightly hurt the performance, but also brings some convenience when using the pprof command, so I enable it in this commit.

   Above discussion is similar to this comment.

   An alternative is to add an API that returns the flamegraph directly, like this example

[BaldDemian]

I doubt the necessity of adding these two scripts in integration tests🤔. A simple curl command may be enough to test the api.

[Copilot]

Pull Request Overview

Adds a new pprof-based heap profiling endpoint to the HTTP server, implements the backend dump logic using jemalloc’s pprof interface, and provides integration scripts to exercise the new API.

• Register /debug/pprof/heap/{seconds} route in the HTTP layer
• Implement dump_heap_pprof in the profiling component with tikv-jemalloc crates
• Add two Python integration scripts for stress testing and requesting the new endpoint

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/server/src/http.rs	Register new pprof heap endpoint, map PprofHeap error variant
src/components/profile/src/lib.rs	Implement dump_heap_pprof, switch to tikv_jemalloc crates
src/components/profile/Cargo.toml	Update dependencies: add jemalloc_pprof, tikv-jemalloc-*
integration_tests/pprof_heap/stress.py	Add SQL workload stress test script (not directly pprof-related)
integration_tests/pprof_heap/request.py	Add script to fetch and save raw heap pprof data

Comments suppressed due to low confidence (2)

src/server/src/http.rs:106

• [nitpick] The error message uses 'Fail to do heap pprof', which is awkward; consider rephrasing to 'Failed to dump heap pprof' for clarity and consistent tense.

#[snafu(display("Fail to do heap pprof, err:{}.\nBacktrace:\n{}", source, backtrace))]

src/components/profile/src/lib.rs:187

• The new dump_heap_pprof method lacks unit tests to validate its behavior; consider adding tests to cover successful pprof dumps and error paths (e.g. uninitialized PROF_CTL).

pub fn dump_heap_pprof(&self, seconds: u64) -> Result<Vec<u8>> {

[Copilot]

[nitpick] Using .. in the warp::path! macro combined with a separate param can be error-prone; consider using warp::path!("debug" / "pprof" / "heap" / u64) to bind the segment directly for clearer routing.

Suggested change

	warp::path!("debug" / "pprof" / "heap" / ..)
	.and(warp::path::param::<u64>())
	warp::path!("debug" / "pprof" / "heap" / u64)

[Copilot]

[nitpick] Since Duration is already imported, you can simplify this to thread::sleep(Duration::from_secs(seconds)); for consistency with existing imports.

Suggested change

	thread::sleep(time::Duration::from_secs(seconds));
	thread::sleep(Duration::from_secs(seconds));

[BaldDemian]

Saw the failing CI checks. Could be related to the changed cargo.toml or cargo.lock. I will try fix them.

[jiacai2050]

@BaldDemian Please don't update this PR anymore, I will try fix those CI errors.

[BaldDemian]

@jiacai2050, thanks for your help! I tried fix these errors this morning but didn't succeed

[jiacai2050]

LGTM