Repository navigation
Description
Background
When syncpoint is enabled, each dispatcher independently sends events to EventCollector.
Under DS memory quota pressure, fast dispatchers can continuously fill shared memory,
while slower dispatchers cannot enqueue enough events to make progress.
This creates unfair progress among dispatchers and hurts overall throughput.
Problem statement
In the current model, EventCollector memory is effectively consumed by whoever sends faster.
There is no global syncpoint-stage coordination in EventBroker to force balanced progress before
moving syncpoint forward.
As a result:
- Fast dispatchers keep advancing and occupy most DS memory quota.
- Slow dispatchers are starved and lag on checkpoint/syncpoint progression.
- Syncpoint completion is delayed by stragglers, causing long tail latency.
- End-to-end throughput drops because the pipeline repeatedly waits on the slowest blocked paths.
ASCII view of the original problem
Before fix (single-dispatcher-driven pushing)
Dispatcher A (fast) ----> EventCollector queue [##########] (quota almost full)
Dispatcher B (slow) --x enqueue blocked / tiny share
Dispatcher C (slow) --x enqueue blocked / tiny share
Shared DS memory quota:
+---------------------------------------------------------------+
| A: 85-95% |
| B: 3-8% |
| C: 2-7% |
+---------------------------------------------------------------+
Syncpoint view:
A: sentResolvedTs/checkpointTs keeps moving
B,C: lagging, cannot catch up
=> global syncpoint commit waits for lagging dispatchers
=> high syncpoint latency + lower throughput
Why this is a performance issue
It is a steady-state performance issue under skewed
workloads: memory quota is monopolized by fast paths, causing starvation and prolonged syncpoint
barriers, which directly reduces throughput and increases p99 latency.
Activity
eventBroker: implement two stage syncpoint (#4429)
Revert "eventBroker: implement two stage syncpoint (#4429)" (#4817)
kennytm commentedon Sep 23, 2026
Since #4429 has been reverted by #4817, this issue should better be reopened, unless one could prove that this has been fixed by some other PRs (#5953?).
asddongmen commentedon Oct 13, 2026
@kennytm
This issue should have been fixed by #4030
eventcollector: prevent syncpoint and redo memory starvation (pingcap…