felix199103 commented on issue #66997:
URL: https://github.com/apache/doris/issues/66997#issuecomment-5355828524
Follow-up on userspace stacks:
BE has ~23k OS threads named `RScan_normal` while pool accounting stays
`r_scan real_num≈8 / max=512`.
gdb attach at this scale is not practical (`info threads` hangs / holds
TracerPid).
`perf record -t <tid>` gets no samples (threads off-CPU).
Sampled OLD TIDs: 7713, 7784, 7788
Sampled NEW TIDs: 3625708, 3625721, 3625785
All: syscall 202 (futex), same userspace PC.
PC=0x7f232e7f3117 → libc.so.6 text
map 7f232e78a000-7f232e91f000 r-xp offset 0x28000
relative=0x91117
Dynsym bracketing (stripped libc, no debuginfo):
prev: __nptl_death_event@0x90f90 (delta +0x187 — NOT inside that fn)
next: __lll_lock_wait_private@0x91230 (~281 bytes after PC)
also nearby: __lll_lock_wake_private, __pthread_cleanup_routine,
__nptl_create_event
So OLD/NEW threads look idle in glibc NPTL low-level wait/futex path,
not obviously differentiated by PC. Full Doris `bt` still missing; will
retry after BE restart when thread count is low, or via off-CPU BPF.
Question: is this futex-PC + dynsym bracket enough to proceed, or do you
need a full `bt` after we restart one BE?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
