[MXS-4100] connection_keepalive=0 causes a memory leak Created: 2022-04-19  Updated: 2022-06-06  Resolved: 2022-06-06

Status: Closed
Project: MariaDB MaxScale
Component/s: Protocol
Affects Version/s: 2.5.20, 6.3.1
Fix Version/s: 2.5.21, 6.4.0

Type: Bug Priority: Critical
Reporter: Oleg Assignee: Niclas Antti
Resolution: Fixed Votes: 3
Labels: None
Environment:

Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-107-generic x86_64)
Server version: 10.6.7-MariaDB-1:10.6.7+maria~focal-log


Attachments: PNG File image-2022-04-19-14-55-55-419.png    
Issue Links:
Duplicate
is duplicated by MXS-4141 connection_keepalive=0 causes a memor... Closed

 Description   

Under heavy load, MaxScale consumes RAM indefinitely. Tested from 2.5.19 to 6.3.0.
The maxscale process constantly increases the memory used until sysbench is stopped

sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=1.1.1.1 --mysql-port=33306 --mysql-user=testuser --mysql-password='testpass' --mysql-db=sbtest --db-driver=mysql --tables=3 --table-size=10000000 --report-interval=10 --threads=400 --time=8000 --db-ps-mode=disable run

On another server with a lot of RAM, I saw 150GB of memory used by the maxscale process in 8 hours of sysbench

[maxscale]
threads=4
skip_name_resolve=true
auth_connect_timeout=20s
query_retries=2
query_classifier_cache_size=0 *(with and without this options)*
writeq_high_water=0 *(with and without this options)*
writeq_low_water=0 *(with and without this options)*
 
[server1]
type=server
address=1.1.1.1
port=3306
extra_port=8385
proxy_protocol=true
persistpoolmax=500 *(with and without this options)*
#persistmaxtime=5m *(with and without this options)*
protocol=MariaDBBackend
 
[server2]
type=server
address=1.1.1.2
port=3306
extra_port=8385
proxy_protocol=true
persistpoolmax=500 *(with and without this options)*
#persistmaxtime=5m *(with and without this options)*
protocol=MariaDBBackend
 
[server3]
type=server
address=1.1.1.3
port=3306
extra_port=8385
proxy_protocol=true
persistpoolmax=500 *(with and without this options)*
#persistmaxtime=5m *(with and without this options)*
protocol=MariaDBBackend
 
[Replication-Monitor]
type=monitor
module=mariadbmon
servers=server1, server2, server3
user=maxscale
password=passwd
failcount=5
monitor_interval=2s
backend_connect_timeout=3s
backend_connect_attempts=2
backend_write_timeout=60s
backend_read_timeout=60s
auto_failover=true
auto_rejoin=true
enforce_read_only_slaves=on
enforce_simple_topology=true
cooperative_monitoring_locks=majority_of_running
 
[Write-Service]
type=service
router=readconnroute
router_options=master
connection_keepalive=0s
servers=server1, server2, server3
user=maxscale
password=passwd
 
[Read-Service]
type=service
router=readconnroute
router_options=slave
connection_keepalive=0s
servers=server1, server2, server3
user=maxscale
password=passwd
 
[Write-Listener]
type=listener
service=Write-Service
protocol=MariaDBClient
port=33306
 
[Read-Listener]
type=listener
service=Read-Service
protocol=MariaDBClient
port=33307



 Comments   
Comment by Oleg [ 2022-04-19 ]

Hmm... I just found the reason was in "connection_keepalive=0s" in the service sections.
However, I think this is a bug.

Comment by markus makela [ 2022-04-19 ]

dzoleg so removing connection_keepalive=0s from the configuration fixes it?

Comment by Oleg [ 2022-04-19 ]

Yes, fixed it. Removing or setting any values except 0s fixes the issue.

Comment by markus makela [ 2022-04-19 ]

Does this happen if you use the readwritesplit router?

Comment by Oleg [ 2022-04-19 ]

This happen on readconnroute router. I don't tested this with other routers, because I need only readconnroute.

Comment by markus makela [ 2022-04-19 ]

If you can test this with readwritesplit, it would tell us whether the problem is only related to the readconnroute or if it's something else.

Comment by Oleg [ 2022-04-19 ]

Looks like no problem with readwritesplit.

Generated at Thu Feb 08 04:26:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.