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

tidb_stats_load_sync_wait Parameter does not take effect #50872

Closed
Chad20N13 opened this issue Feb 1, 2024 · 10 comments · Fixed by #50915
Closed

tidb_stats_load_sync_wait Parameter does not take effect #50872

Chad20N13 opened this issue Feb 1, 2024 · 10 comments · Fixed by #50915
Labels
severity/moderate sig/planner SIG: Planner type/bug The issue is confirmed as a bug.

Comments

@Chad20N13
Copy link

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

set global tidb_stats_load_sync_wait=30000;

2. What did you expect to see? (Required)

execute SQL need to wait 30 seconds

3. What did you see instead (Required)

SQL return result in 3 seconds, and report a warning : sync load stats timeout

4. What is your TiDB version? (Required)

MySQL [lifedata]> select tidb_version();
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| tidb_version() |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Release Version: v7.5.0
Edition: Community
Git Commit Hash: 069631e
Git Branch: heads/refs/tags/v7.5.0
UTC Build Time: 2023-11-24 08:50:14
GoVersion: go1.21.3
Race Enabled: false
Check Table Before Drop: false
Store: tikv |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

@Chad20N13 Chad20N13 added the type/bug The issue is confirmed as a bug. label Feb 1, 2024
@Chad20N13
Copy link
Author

image

@Chad20N13
Copy link
Author

image (1)

@jiyfhust
Copy link
Contributor

jiyfhust commented Feb 1, 2024

Is sql hint max_execution_time or session/global variable max_execution_time set a small value?
It looks will choose the smallest value as the actual waitTime.

waitTime := min(syncWait, hintMaxExecutionTime, sessMaxExecutionTime)

waitTime := min(syncWait, hintMaxExecutionTime, sessMaxExecutionTime)

@jiyfhust
Copy link
Contributor

jiyfhust commented Feb 1, 2024

There maybe a bug, not very sure about yet:

syncWait := plan.SCtx().GetSessionVars().StatsLoadSyncWait * time.Millisecond.Nanoseconds()

infact StatsLoadSyncWait is ms unit.

and MaxExecutionTime is ms unit too.

However Compare syncWait with MaxExecutionTime is not right, is it?

Not sure if #50915 can close it.

@jiyfhust
Copy link
Contributor

jiyfhust commented Feb 2, 2024

There maybe a bug, not very sure about yet:

syncWait := plan.SCtx().GetSessionVars().StatsLoadSyncWait * time.Millisecond.Nanoseconds()

infact StatsLoadSyncWait is ms unit.

and MaxExecutionTime is ms unit too.

However Compare syncWait with MaxExecutionTime is not right, is it?

Not sure if #50915 can close it.

@hawkingrei PTAL

syncWait := plan.SCtx().GetSessionVars().StatsLoadSyncWait * time.Millisecond.Nanoseconds()

waitTime := min(syncWait, hintMaxExecutionTime, sessMaxExecutionTime)

@jebter jebter added the sig/planner SIG: Planner label Feb 2, 2024
@Chad20N13
Copy link
Author

max_execution_time is 86400000

@Chad20N13
Copy link
Author

image

@jiyfhust
Copy link
Contributor

jiyfhust commented Feb 4, 2024

max_execution_time is 86400000

There maybe a bug, not very sure about yet:

syncWait := plan.SCtx().GetSessionVars().StatsLoadSyncWait * time.Millisecond.Nanoseconds()

infact StatsLoadSyncWait is ms unit.

and MaxExecutionTime is ms unit too.

However Compare syncWait with MaxExecutionTime is not right, is it?

Not sure if #50915 can close it.

The syncWait will be 86400000Nanoseconds, that is 86.4ms。Then reported timeout error.
The total time is 3.02s, is it a slow query even there is no need to load stats?

@Chad20N13
Copy link
Author

tidb_stats_load_sync_wait is 30000
max_execution_time is 86400000

max_execution_time
Scope: SESSION | GLOBAL
Persists to cluster: Yes
Applies to hint SET_VAR: Yes
Type: Integer
Default value: 0
Range: [0, 2147483647]
Unit: Milliseconds
The maximum execution time of a statement. The default value is unlimited (zero).

I do not know the logic or time unit of these two parameters, please analyze the problem in detail .

@jiyfhust
Copy link
Contributor

/severity moderate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity/moderate sig/planner SIG: Planner type/bug The issue is confirmed as a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants