KVStore: Reduce lock contention in RegionPersister::doPersist

[JaySon-Huang]

What problem does this PR solve?

Issue Number: close #8583

Problem Summary:

tiflash/dbms/src/Storages/KVStore/MultiRaft/RegionPersister.cpp

Lines 99 to 125 in 5980908

	void RegionPersister::doPersist(
	RegionCacheWriteElement & region_write_buffer,
	const RegionTaskLock & region_task_lock,
	const Region & region)
	{
	auto & [region_id, buffer, region_size, applied_index] = region_write_buffer;
	std::lock_guard lock(mutex);
	auto entry = page_reader->getPageEntry(region_id);
	if (entry.isValid() && entry.tag > applied_index)
	return;
	if (region.isPendingRemove())
	{
	LOG_DEBUG(log, "no need to persist {} because of pending remove", region.toString(false));
	return;
	}
	auto read_buf = buffer.tryGetReadBuffer();
	RUNTIME_CHECK_MSG(read_buf != nullptr, "failed to gen buffer for {}", region.toString(true));
	DB::WriteBatchWrapper wb{run_mode, getWriteBatchPrefix()};
	wb.putPage(region_id, applied_index, read_buf, region_size);
	page_writer->write(std::move(wb), global_context.getWriteLimiter());
	region.updateLastCompactLogApplied(region_task_lock);
	}

RegionPersister::doPersist acquires a lock and calls PageStorage::write with the lock. This means when we're persisting Region meta, all other threads can not do the persistence for other Region meta. Which is not reasonable.

What is changed and how it works?

There is a region_task_lock to ensure that only one thread could call RegionPersister::doPersist for the same region_id at the same time. And PageStorage support multi-thread reading and writing for different page_id. There is no need to acquire another lock in RegionPersister::doPersist that could slowdown the raft apply process

And also remove calling KVStore::persistRegion with a null region_task_lock. So we can simplify codes and remove the member RegionPersister:: RegionManager

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Reduce the impact of disk performance jitter on read latency

[JaySon-Huang]

/run-all-tests

[JaySon-Huang]

/run-all-tests

[CalvinNeo]

lgtm

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: CalvinNeo, Lloyd-Pottiger

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [CalvinNeo,Lloyd-Pottiger]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2023-12-26 09:50:26.515807008 +0000 UTC m=+1559317.553033929: ☑️ agreed by CalvinNeo.
• 2023-12-26 09:56:39.045213705 +0000 UTC m=+1559690.082440617: ☑️ agreed by Lloyd-Pottiger.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-5.4: #8595.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-6.1: #8596.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-6.5: #8597.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-7.1: #8598.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-7.5: #8599.

[JaySon-Huang]

Change the release note from "write throughput" to "read latency"

Tests with some failpoint injects (99%-10ms and %0.7-100ms and %0.2-1000ms) latency on RegionPersister::doPersist show that the changes mainly affect the read latency caused by wait index but not the write throughput