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

sql: determine a reasonable default for server.max_open_transactions_per_gateway #124318

Open
rafiss opened this issue May 17, 2024 · 1 comment
Labels
C-investigation Further steps needed to qualify. C-label will change. O-postmortem Originated from a Postmortem action item. P-3 Issues/test failures with no fix SLA T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)

Comments

@rafiss
Copy link
Collaborator

rafiss commented May 17, 2024

Is your feature request related to a problem? Please describe.
We recently created the server.max_open_transactions_per_gateway cluster setting. When set, it limits the number of concurrently open transactions on a single node. This was added because under high concurrency, CockroachDB does not perform well (though the performance issues may mostly have been due to the bug described in #123235). The default is 0 right now, which means that most users will not see value from the cluster setting.

We recommend that users size their connection pools to 4 * CPUs in our docs for similar reasons; to guard against overloading the cluster.

Describe the solution you'd like
Set the default to something like GOMAXPROCS * constant. A reasonable constant may be hard to identify. We shouldn't pick something too low, since that will cause breakage and errors for clusters that temporarily reach high amounts of concurrency. Picking a value that's too high may mean that the setting doesn't really do anything, but it's definitely safer.

An issue is that different nodes may have different GOMAXPROCS. So rather than actually persisting the default value, we probably just want to make it so that the GOMAXPROCS * constant calculation is used if the setting is not set.

We could define a negative setting as the scale factor for GOMAXPROCS. So a value of -32 would mean that 32 * GOMAXPROCS concurrent open transactions are allowed.

Describe alternatives you've considered
Keep it opt-in. Users can set it if they are aware of it.

Also, as the admission control system improves, this setting will become less important.

Additional context
See the takeaways from an outage where this setting would have helped. https://cockroachlabs.atlassian.net/wiki/x/zICD1

Jira issue: CRDB-38820

@rafiss rafiss added C-investigation Further steps needed to qualify. C-label will change. T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions) O-postmortem Originated from a Postmortem action item. P-3 Issues/test failures with no fix SLA labels May 17, 2024
@blathers-crl blathers-crl bot added this to Triage in SQL Foundations May 17, 2024
@rafiss
Copy link
Collaborator Author

rafiss commented May 28, 2024

We will leave this as-is for now, and we can prioritize it if we see that more customers could benefit from this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-investigation Further steps needed to qualify. C-label will change. O-postmortem Originated from a Postmortem action item. P-3 Issues/test failures with no fix SLA T-sql-foundations SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Projects
SQL Foundations
  
Triage
Development

No branches or pull requests

1 participant