Skip to content

Syncpoint-enabled throughput drop due to dispatcher memory-quota starvation #4605

Closed

Description

@asddongmen

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

  1. self-assigned this
    on Mar 27, 2026
  2. added a commit that references this issue on Mar 31, 2026
    fa1e59c
  3. kennytm commented on Sep 23, 2026

    @kennytm
    Contributor

    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?).

  4. asddongmen commented on Oct 13, 2026

    @asddongmen
    CollaboratorAuthor

    8. 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?).

    @kennytm
    This issue should have been fixed by #4030

  5. added
    type/bugThe issue is confirmed as a bug.
    affects-8.5This bug affects the 8.5.x(LTS) versions.
    affects-26.9This bug affects the TiDB X 26.9.x versions.
    and removed
    type/enhancementThe issue or PR belongs to an enhancement.
    on Oct 22, 2026
  6. added a commit that references this issue on Nov 7, 2026
    d26cabf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

affects-26.9This bug affects the TiDB X 26.9.x versions.affects-8.5This bug affects the 8.5.x(LTS) versions.severity/moderatetype/bugThe issue is confirmed as a bug.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions