-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
show session variables is very slow on first run #24326
Comments
The problem is more complicated to fix than I first thought. The easy fix is to change The more complex fix is to improve the caching layer for sysVars to separate global scoped variables and session scoped variables. When a new session is created, it should copy the session-scoped cache immediately (this is MySQL behavior; currently TiDB does not follow this exactly because it lazy-loads the session vars.) Improving the caching layer also means that read-after-write consistency can be ensured. This is not provided by the current global value cache, and the testsuite does non-MySQL compatible things to ensure it: Lines 2573 to 2580 in dbecb9e
(There are other occurences of this, and this issue is not just affecting the testsuite. I've also noticed it when scripting against TiDB, since global changes even on a local server are not immediate.) The global variable cache uses a 2 second TTL, and doesn't actually notify other TiDB servers that the cache is out of date and needs to be reloaded. A more friendly design would be to use the same as the privilege system which uses a 5 minute TTL and subscribes to updates via etcd notifications. This makes both the cache more useful, and also the updates on other TiDB servers can be reduced to less than 2 seconds in most cases. |
Good catch, here is another report https://asktug.com/t/topic/69936 |
This relates to #24368 - the subsequent "fast" runs of |
Please edit this comment or add a new comment to complete the following informationBugNote: Make Sure that 'component', and 'severity' labels are added 1. Root Cause Analysis (RCA) (optional)Global variables are expected to show in 2. Symptom (optional)Any latency betweeen tidb and the tikv region which stores the config information increases the impact of this issue, resulting in some users reporting close to 1 second delay. 3. All Trigger Conditions (optional)4. Workaround (optional)Use a connection pool, and pre-run SHOW VARIABLES. Short lived connections or short lived pools exhibit the slow cache issue the worst. 5. Affected versions[v4.0.1:v4.0.12], [v5.0.0:v5.0.1] 6. Fixed versionsmaster |
( AffectedVersions ) fields are empty. |
@morgo do you refer to |
Yes. |
may I know why this issue is closed? |
This has been fixed with the introduction of sysvar cache in master. The sysvar cache functions differently to the previous global variables cache in that it invalidates the cache when changes are made. Regeneration is also handled in the background. |
Bug Report
This is reported here:
https://asktug.com/t/topic/69586
https://asktug.com/t/topic/69767
https://asktug.com/t/topic/69699
1. Minimal reproduce step (Required)
SHOW VARIABLES
in a new session2. What did you expect to see? (Required)
It should always be fast.
3. What did you see instead (Required)
The first execution is slow.
4. What is your TiDB version? (Required)
Verified against master:
The text was updated successfully, but these errors were encountered: