[#2558] improvement(server): Limit the max flush event count for a single buffer

[xianjingfeng]

What changes were proposed in this pull request?

Limit the max flush event count for a single buffer.

Why are the changes needed?

Fix: #2558

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Verify in production environment.

[github-actions]

Test Results

 3 082 files  ±0   3 082 suites  ±0   6h 48m 9s ⏱️ - 1m 48s
 1 193 tests ±0   1 192 ✅ ±0   1 💤 ±0  0 ❌ ±0 
15 123 runs  ±0  15 108 ✅ ±0  15 💤 ±0  0 ❌ ±0 

Results for commit 5d36f38. ± Comparison against base commit 1713c1f.

♻️ This comment has been updated with latest results.

[jerqi]

@zuston Could you help me review this PR? I thought this is used for huge partition, too.

[zuston]

The single-buffer triggered event will be added to the flushing queue. To improve the maximum flushing throughput, would it be possible to assign different priorities to these events? @xianjingfeng

[xianjingfeng]

The single-buffer triggered event will be added to the flushing queue. To improve the maximum flushing throughput, would it be possible to assign different priorities to these events? @xianjingfeng

@zuston I think this is not very useful, because even if the event is put into the flush queue, if the flush speed of a single buffer can't keep up, the memory can't be released. The difference is whether to keep the blocks in the memory into blocksMap or inFlushBlockMap.

[zuston]

Got it. LGTM.

[xianjingfeng]

@zuston Thanks for your review.