Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duration of analyze partition table increased more than 50x #8500

Closed
apollodafoni opened this issue Aug 7, 2024 · 3 comments · Fixed by #8505
Closed

Duration of analyze partition table increased more than 50x #8500

apollodafoni opened this issue Aug 7, 2024 · 3 comments · Fixed by #8505
Assignees
Labels
severity/critical type/bug The issue is confirmed as a bug.

Comments

@apollodafoni
Copy link

Bug Report

What did you do?

  1. create partition table

CREATE TABLE t1 (
id int(11) NOT NULL AUTO_INCREMENT,
k int(11) NOT NULL DEFAULT '0',
c char(120) NOT NULL DEFAULT '',
pad char(60) NOT NULL DEFAULT '',
PRIMARY KEY (id) /*T![clustered_index] CLUSTERED */
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=100279
PARTITION BY HASH (id) PARTITIONS 1000

  1. insert 100000 rows data
  2. analyze table t1

What did you expect to see?

Analyze finishes in a shorter time.
According to previous test experience, it is within 100s.
The most recent successful test was 37s.

What did you see instead?

"analyze time: "=1929.67098683
Sometimes it can be as long as 4,000 seconds .
A lot of time is spent on: merging global stats for test.t1 columns
The performance degradation is very serious

What version of PD are you using (pd-server -V)?

After testing, it was confirmed that this PR(#8377) caused it

@apollodafoni apollodafoni added the type/bug The issue is confirmed as a bug. label Aug 7, 2024
@apollodafoni
Copy link
Author

/severity critical

@apollodafoni
Copy link
Author

/assign @rleungx

@apollodafoni apollodafoni changed the title The time to analyze partition table increased more than 50x Duration of analyze partition table increased more than 50x Aug 7, 2024
@rleungx
Copy link
Member

rleungx commented Aug 8, 2024

The issue happens due to:

  1. There is only one TiKV with 3 replicas setting, which results in keeping adding replicas but fails. It costs around one core
  2. PD only has one core used up because of 1.
  3. The previous cache has a TTL mechanism. After 3min, it will stop adding replicas

The above reason causes TSO requests to become very slow and affects the analyze table speed.

ti-chi-bot bot added a commit that referenced this issue Aug 8, 2024
close #8500

Signed-off-by: Ryan Leung <rleungx@gmail.com>

Co-authored-by: ti-chi-bot[bot] <108142056+ti-chi-bot[bot]@users.noreply.github.com>
@ti-chi-bot ti-chi-bot bot closed this as completed in #8505 Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity/critical type/bug The issue is confirmed as a bug.
Projects
Development

Successfully merging a pull request may close this issue.

2 participants