Skip to content

branch-4.1: [fix](be) Avoid per-fd stat when counting process fds in metrics #67945 - #68046

Merged
yiguolei merged 1 commit into
branch-4.1from
auto-pick-67945-branch-4.1
Sep 16, 2026
Merged

yiguolei merged 1 commit into
branch-4.1from
auto-pick-67945-branch-4.1

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

Cherry-picked from #67945

)

[fix](be) Avoid per-fd stat when counting process fds in metrics

### What problem does this PR solve?

Issue Number: close #67777

Problem Summary: `DorisMetrics::_update_process_fd_num()` counts entries
under `/proc/self/fd` with `entry.is_regular_file()`, which follows
every symlink with a `stat()` syscall. With ~200k open fds this takes
~0.6s per run, and the hook runs under the `MetricRegistry` lock every
15 s, stalling `/metrics` scrapes for hundreds of milliseconds. This PR
counts the directory entries directly (readdir only), which is about 5x
cheaper while still reflecting the number of open fds. The remaining
stalls (hooks running under the registry lock, stream load blocking
webserver workers) are tracked as follow-ups.

### Release note

None

### Check List (For Author)

- Test: No need to test (with reason) - behavior preserved (fd count),
only the per-entry stat syscalls are removed
- Behavior changed: No
- Does this need documentation: No

Co-authored-by: Asthenia0412 <Asthenia0412@users.noreply.github.com>
@github-actions
github-actions Bot requested a review from yiguolei as a code owner September 16, 2026 03:07
@hello-stephen

Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@hello-stephen

Copy link
Copy Markdown
Contributor

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

BE UT Coverage Report

Increment line coverage 0.00% (0/5) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 59.85% (25990/43427)
Line Coverage 44.57% (268415/602192)
Region Coverage 40.43% (213008/526830)
Branch Coverage 41.91% (98468/234968)

@hello-stephen

Copy link
Copy Markdown
Contributor

BE Regression && UT Coverage Report

Increment line coverage 100.00% (5/5) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 74.47% (31464/42252)
Line Coverage 58.76% (351020/597402)
Region Coverage 55.54% (293266/528028)
Branch Coverage 56.36% (132292/234708)

@yiguolei
yiguolei merged commit f0fab59 into branch-4.1 Sep 16, 2026
40 of 42 checks passed
@github-actions

Copy link
Copy Markdown
Contributor Author

PR approved by anyone and no changes requested.

@github-actions github-actions Bot added the approved Indicates a PR has been approved by one committer. label Sep 16, 2026
@github-actions

Copy link
Copy Markdown
Contributor Author

PR approved by at least one committer and no changes requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. reviewed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants