sollhui opened a new pull request, #68328:
URL: https://github.com/apache/doris/pull/68328
### What problem does this PR solve?
When load writes, flush waits, or closes occupy the shared BRPC heavy pool,
`tablet_writer_open`, `tablet_writer_cancel`, and `open_load_stream` queue
behind that work. In particular, a cancellation intended to release load
resources cannot be dispatched promptly under heavy-pool saturation.
Add two dedicated load pools:
- `brpc_load_light`: writer open/cancel and stream open.
- `brpc_load_heavy`: add-block RPCs (including the HTTP forwarding path) and
`LoadStreamMgr` flush/pre-close/close tasks.
Both pools have independent thread/queue settings and queue-size,
active-thread, effective thread-limit, and effective queue-limit metrics. The
four new `brpc_load_{heavy,light}_work_pool_{threads,max_queue_size}` settings
require a restart and accept `-1` or a positive value. By default, load-heavy
inherits the existing heavy-pool settings; load-light uses `max(32, CPU cores)`
threads and `max(1024, CPU cores * 32)` queued requests.
The split reserves execution capacity for load control requests. It does not
remove locks or storage operations inside open/cancel, and it creates
additional fixed worker threads. Existing generic heavy/light pools, RPC
response contracts, and storage/transaction semantics are retained. No
throughput or latency benchmark is claimed.
### Release note
Isolate load open and cancellation RPCs from load write/close queues to
reduce control-request queueing under load. Add independently configurable
load-heavy and load-light BRPC worker pools and metrics.
### Check List (For Author)
- Test
- [x] Unit Test: added deterministic queue-routing and queue-full
callback/status coverage for writer open/cancel, stream open, and add-block,
plus streaming close-pool wiring. **Not executed**, as requested by the author.
- Validation completed: clang-format 16.0.5 on all five changed C++
files and `git diff --check`.
- Build/UT execution skipped at the author's request. An initial
build-environment probe was stopped during third-party dependency setup; no BE
build or test result is claimed.
- Behavior changed:
- [x] Yes. Load control and data requests use separate pools; existing
generic RPC pools retain their configuration names.
- Does this need documentation?
- [x] No separate documentation change in this PR. New tuning defaults
and restart requirements are documented alongside the BE configuration
declarations.
### Review notes
- Concurrency: only dispatch destinations change; handlers retain their
existing locks and memory-tracking contexts. The new pools introduce no new
lock order.
- Lifetime: pools remain owned by `PInternalService`; `LoadStreamMgr`
borrows its load-heavy pool using the existing ownership model. New metric
hooks are deregistered on destruction.
- Compatibility: no protobuf, persistent format, FE variable, visibility, or
transaction protocol change.
- Parallel paths: HTTP add-block delegates to the modified RPC; streaming
open and flush/close are included; shared service dispatch covers cloud and
local storage modes.
- Failure handling: queue rejection reports the destination pool and
preserves exactly-once completion behavior, including the empty cancellation
response.
- Coverage limit: the added tests cover dispatch/backpressure and wiring;
end-to-end load behavior and performance were not exercised.
--
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]
