Fly-Style opened a new pull request, #18936:
URL: https://github.com/apache/druid/pull/18936

   ## Core ideas around the change
   - Scale up more aggressively when per-partition lag is meaningful.
   - Relax the PPT (partitions-per-task) increase limit based on lag severity 
and headroom.
   - Keep behavior conservative near `taskCountMax` and avoid negative headroom 
effects.
   
   ## Key changes
   - **Lag-proportional PPT relaxation**: add `rawExtra` when lag/partition 
exceeds thresholds, plus a step function for higher lag.
   - **Headroom-aware scaling**: multiply by `max(0, 1 - 
currentTasks/maxTasks)` to reduce aggressiveness near max and avoid negative 
scaling.
   - **No fractional PPT**: PPT remains integer; when PPT is already 1, 
scale-up is limited only by `taskCountMax`.
   - **Lag-amplified idle decay**: when lag/partition exceeds the activation 
threshold, the lag-based busy factor is multiplied 
       by a ramped multiplier (1.0x at 50K to 2.0x at 500K) to reduce predicted 
idle more aggressively during high lag.
   
   ## Expected behavior (for example, 30 partitions, `taskCountMax`=30)
   - 3 tasks: 50K lag/partition → 8 tasks; 300K → 15 tasks; 500K+ → 30 tasks.
   - 10 tasks: 100K → 15; 300K → 30; 500K → 30.
   - 20/25 tasks (PPT=1): scale-up capped only by `taskCountMax`.
   Note: examples assume lag-dominant conditions (low/mide processing rate, low 
idle).
   
   ## Open questions / risks
   - **Lag skew**: using `aggregateLag / partitionCount` can under-react if a 
few partitions are far behind. Consider max/percentile lag if available.
   
   ## Potential (further) calibration plan
   - Replay historical metrics from `CostBasedAutoScaler#collectMetrics` 
(aggregate lag, partition count, current/max tasks, poll idle ratio).
   - Sweep parameters with aggressive bias:
     - `LAG_ACTIVATION_THRESHOLD` in [25K, 50K]
     - `BASE_RAW_EXTRA` in [5, 7, 9]
     - `LAG_STEP` in [50K, 100K]
     - set `LAG_AGGRESSIVE_THRESHOLD = 2 × LAG_ACTIVATION_THRESHOLD` unless 
replay shows early maxing out
   - Choose the most aggressive config that keeps overshoot and oscillation 
acceptable.
   - Guardrails during rollout:
     - cap per-cycle task increase, e.g. `min(10, 0.2 * (taskCountMax - 
currentTaskCount))`
     - minimum dwell time before another scale-up when lag barely exceeds 
activation
     - alert on `currentTaskCount > taskCountMax`
   
   This PR has:
   
   - [ ] been self-reviewed.
      - [ ] using the [concurrency 
checklist](https://github.com/apache/druid/blob/master/dev/code-review/concurrency.md)
 (Remove this item if the PR doesn't have any relation to concurrency.)
   - [ ] added documentation for new or modified features or behaviors.
   - [ ] a release note entry in the PR description.
   - [ ] added Javadocs for most classes and all non-trivial methods. Linked 
related entities via Javadoc links.
   - [ ] added or updated version, license, or notice information in 
[licenses.yaml](https://github.com/apache/druid/blob/master/dev/license.md)
   - [ ] added comments explaining the "why" and the intent of the code 
wherever would not be obvious for an unfamiliar reader.
   - [ ] added unit tests or modified existing tests to cover new code paths, 
ensuring the threshold for [code 
coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md)
 is met.
   - [ ] added integration tests.
   - [ ] been tested in a test Druid cluster.


-- 
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]

Reply via email to