[Enhancement] Expose jemalloc runtime options as be config#75344
Conversation
Signed-off-by: trueeyu <lxhhust350@qq.com>
|
No new undocumented parameters detected by the param-drift check. |
There was a problem hiding this comment.
Pull request overview
This PR makes the BE/CN jemalloc startup configuration observable via information_schema.be_configs by introducing a new immutable BE config (jemalloc_conf) and wiring normal-mode startup to export JEMALLOC_CONF from be.conf/cn.conf (with a default matching the existing behavior).
Changes:
- Added immutable BE config
jemalloc_conf(string) to surface the normal-mode jemalloc option string viaconfig::list_configs(). - Updated
bin/start_backend.shnormal-mode startup to readjemalloc_conffrombe.conf/cn.confand export it asJEMALLOC_CONF, falling back to the built-in default.
Reviewed changes
Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| bin/start_backend.sh | Reads jemalloc_conf from be/cn conf in normal mode and exports it as JEMALLOC_CONF for process startup. |
| be/src/common/config.h | Declares new immutable jemalloc_conf config (defaulted to current normal-mode jemalloc string) for SQL observability. |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Signed-off-by: trueeyu <lxhhust350@qq.com>
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[FE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[BE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3e0ee38a82
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3e0ee38a82
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Tick the box to add this pull request to the merge queue (same as
|
|
@Mergifyio backport branch-4.1 |
✅ Backports have been createdDetails
|
Why I'm doing this:
The jemalloc runtime options used by BE/CN are currently set only as the
JEMALLOC_CONFenvironment variable insidebin/start_backend.sh. Becauseinformation_schema.be_configsis populated purely fromconfig::list_configs()(i.e. items declared inbe/src/common/config.h), this value is invisible there — there is no way to confirm via SQL which jemalloc options a running BE/CN was started with.What I'm doing:
jemalloc_conf(CONF_String, immutable) inbe/src/common/config.h, defaulting to the normal-mode jemalloc option string. This makes the value queryable throughinformation_schema.be_configs.bin/start_backend.sh, the normal startup path (neither--jemalloc_debugnor--check_mem_leak) now readsjemalloc_conffrombe.conf/cn.confand exports it asJEMALLOC_CONF, falling back to the built-in default when unset. The--jemalloc_debugand--check_mem_leakmodes keep forcing their ownJEMALLOC_CONFvalues and ignore the config, as before.Note: jemalloc reads
JEMALLOC_CONFduring process init, before BE config parsing, so this config does not reconfigure jemalloc at runtime — it serves as the single source of truth for the startup script and for observability. The script default and theconfig.hdefault are kept in sync (commented in both places).What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check: