Closed paulomach closed 2 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 66.56%. Comparing base (
e7c1809
) to head (ae74a89
). Report is 17 commits behind head on main.:exclamation: Current head ae74a89 differs from pull request most recent head c443bd3
Please upload reports for the commit c443bd3 to get more accurate results.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Hi all, after discussing about this here and internally, I think I should request this patch to be on hold for the time being.
The fundamental challenge is not immediately solved at this point, and the proposed patch is good as is to prevent the OOM from happening. However, it will limit the available max_connections to 25% from the current state and that may make it harder to run workload with a machine with a fair amount of memory. Until we fix the original challenge, I think it might be better to leave it as is since 1. OOM doesn't happen immediately after the service start and 2. MySQL dynamically allocates memory for actually data in innodb buffer pool size and for incoming connections. So we can keep this optimistic way of memory allocation for the time being.
In the meantime, I appreciate @paulomach for taking the initiative on this matter so far.
please don't merge without my explicit approval
@delgod is it still valid blocker?
Issue
Max connections calculations is not considering already allocated memory for
innodb_buffer_pool_size
, resulting in overcommit (and OOM kill risk)Solution
max_connections
based on the available memory after allocatinginnodb_buffer_pool_size
.experimental-max-connections
configuration allowing independent tuning (as agreement with PM in Madrid)Fixes #407