sessionctx: change @@tidb_enable_gogc_tuner default value to 0

[tiancaiamao]

What problem does this PR solve?

Issue Number: ref #36503

Problem Summary:

What changed and how does it work?

We prefer stability (jitters, OOM risk, unpredictable latency etc) over performance.
In essential, gogc_tuner is trading stability for performance, it works by reducing Go GC frequency to get better throughput and improve the performance.
Maybe in POC or when the memory usage of the workload is low, we can choose performance first, otherwise it's better to work with the default Go GC settings.

This commit change the default value of @@tidb_enable_gogc_tuner from true to false.
It only affect the new bootstraped cluster, the stored global session variable is not changed,
so upgradation of the old clusters do not affect by this change (they can update this session variable depends on their need).

Check List

Tests

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

  • I checked and no code files have been changed.

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

Please refer to Release Notes Language Style Guide to write a quality release note.

Change @@tidb_enable_gogc_tuner default value to 0, tidb memory usage may reduce by this change. Only affect the newly bootstrapped cluster.

[tiprow]

Hi @tiancaiamao. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[codecov]

Codecov Report

Merging #49420 (265ab11) into master (161107a) will increase coverage by 9.4471%.
Report is 1070 commits behind head on master.
The diff coverage is 100.0000%.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #49420        +/-   ##
================================================
+ Coverage   71.0551%   80.5023%   +9.4471%     
================================================
  Files          1368       2604      +1236     
  Lines        401291     762301    +361010     
================================================
+ Hits         285138     613670    +328532     
- Misses        96328     125088     +28760     
- Partials      19825      23543      +3718     

Flag	Coverage Δ
integration	53.7657% <ø> (?)
unit	79.4331% <100.0000%> (+8.3780%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	73.6130% <ø> (+19.6466%)	⬆️
parser	∅ <ø> (∅)
br	71.3099% <ø> (+18.4164%)	⬆️

[jackysp]

LGTM

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jackysp
Once this PR has been reviewed and has the lgtm label, please assign easonn7 for approval. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS [jackysp]
• pkg/sessionctx/variable/OWNERS

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-13 08:57:59.627988909 +0000 UTC m=+432970.665215832: ☑️ agreed by jackysp.

[bb7133]

We prefer stability (jitters, OOM risk, unpredictable latency etc) over performance.

I agree with you about this, but could you please provide some real-scenario case that GOGC Tuner leads to stableness issue? IMO it is just designed to provide a 'smart' timeing for GC.

[tiancaiamao]

See what's the attitude from the kernel developers of Go team:

This out-of-memory avoidance led to the Go community developing its own homegrown garbage collector tuning.

The first example of such tuning is the heap ballast. In order to increase their productivity metrics while also avoiding out-of-memory errors, users sometimes pick a low GOGC value, and fool the GC into thinking that there's a fixed amount of memory live. This solution elegantly scales with GOGC: as the real live heap increases, the impact of that fixed set decreases, and GOGC's contribution to the heap size dominates. In effect, GOGC is larger when the heap is smaller, and smaller (down to its actual value) when the heap is larger. Unfortunately, this solution is not portable across platforms, and is not guaranteed to continue to work as the Go runtime changes. Furthermore, users are forced to do complex calculations and estimate runtime overheads in order to pick a heap ballast size that aligns with their memory limits.

The second example of such tuning is calling runtime/debug.FreeOSMemory at some regular interval, forcing a garbage collection to trigger sooner, usually to respect some memory limit. This case is much more dangerous, because calling it too frequently can lead a process to entirely freeze up, spending all its time on garbage collection. Working with it takes careful consideration and experimentation to be both effective and avoid serious repercussions.

Ref golang/go#48409
Ref https://github.com/golang/proposal/blob/master/design/48409-soft-memory-limit.md

We're doing all anti-best practice things

[kennytm]

Is this still being worked on? I think we've encountered a real-world customer issue that the gctuner mistakenly set $GOGC to 500 similar to pingcap/tiflow#9762 (which eventually causes us to disable gctuner on TiCDC by default).

EDIT: disregard, it is because of the customer manually changing @@tidb_server_memory_limit.