Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Incomplete
-
6.4.14
-
None
-
MXS-SPRINT-211
Description
If MaxScale is configured with query_classifier_cache_size=0 and there are many short connections to the service, the MaxScale instance appears to leak memory. This goes on until the process is killed by the OOM killer.
So far there's been no way to reproduce this outside of the system in question and the number one theory at this point is memory fragmentation that happens somewhere in the SQLite library.
Attachments
Issue Links
- split from
-
-
- Closed
-
Activity
| Fix Version/s | 6.4 [ 26119 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Needs Feedback [ 10501 ] |
| Rank | Ranked higher |
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Priority | Critical [ 2 ] | Blocker [ 1 ] |
| Sprint | MXS-SPRINT-211 [ 762 ] |
| Rank | Ranked lower |
| Rank | Ranked higher |
| Summary | lazy_connect=true with short connections appears to leak memory | query_classifier_cache_size=0 with short connections appears to leak memory |
| Description |
If readwritesplit is configured with {{lazy_connect=true}} and there are many short connections to the service, the MaxScale instance appears to leak memory. This goes on until the process is killed by the OOM killer.
|
If MaxScale is configured with {{query_classifier_cache_size=0}} and there are many short connections to the service, the MaxScale instance appears to leak memory. This goes on until the process is killed by the OOM killer.
So far there's been no way to reproduce this outside of the system in question and the number one theory at this point is memory fragmentation that happens somewhere in the SQLite library. |
| Fix Version/s | N/A [ 22001 ] | |
| Fix Version/s | 21.06 [ 26119 ] | |
| Resolution | Incomplete [ 4 ] | |
| Status | Needs Feedback [ 10501 ] | Closed [ 6 ] |
| Zendesk Related Tickets | 201723 | |
| Zendesk active tickets | 201723 |
| Zendesk active tickets | 201723 |