[MDEV-17146] Memory leak on multiple reuse of prepared statement Created: 2018-09-06  Updated: 2018-11-01  Resolved: 2018-11-01

Status: Closed
Project: MariaDB Server
Component/s: Prepared Statements
Affects Version/s: 10.1.26
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Mariusz Gronczewski Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: need_feedback
Environment:

Debian stable, package 10.1.26-0+deb9

Attachments: PNG File Zaznaczenie_2018-09-06_001.png     File leak-dump.pcap     File schema.sql    

 Description   

See attached screenshot for memory stats. MariaDB is biggest running process in system and it has only ~100MB database (it is slave)

We've upgraded version of mysql that runs our PowerDNS instances (and PowerDNS version itself) and noticed they started leaking memory.

After closer inspection via wireshark I've noticed PowerDNS just makes one prepared statement then constantly executes and resets it, which leads me to believe there is a leak somewhere. After restarting PowerDNS (which ends the connection to MariaDB), memory is freed.

The prepared statement is made to a view if that has any significance

 Comments   
Comment by Alice Sherepa [ 2018-09-10 ]

xani, could you please provide the test case to demonstrate the problem and your configuration of the server.

Comment by Mariusz Gronczewski [ 2018-09-10 ]

There lies the problem, I have been trying to come up with test case but the code that causes it is in C++ ( https://github.com/PowerDNS/pdns/blob/master/modules/gmysqlbackend/smysql.cc ) and I haven't been able to reproduce same results with tools I normally use (I don't know C++, only Perl and Go).

From what I can see in wireshark, PDNS does prepare then (request execute-> response >reset state) for each new request leak-dump.pcap. Other libs(I've tried Go one) only do execute>response, then repeat execute without resetting.

It also does NOT happen when querying records table directly, only when querying a view records_public or records_private schema.sql which is even weirder

[mysqld]
 
basedir = /usr
 
bind-address = 0.0.0.0
 
datadir = /var/lib/mysql
 
expire_logs_days = 10
 
innodb_file_per_table = 1
 
key_buffer_size = 16M
 
log-error = /var/log/mysql/error.log
 
max_allowed_packet = 16M
 
max_binlog_size = 100M
 
max_connections = 151
 
pid-file = /var/run/mysqld/mysqld.pid
 
port = 3306
 
query_cache_limit = 1M
 
query_cache_size = 16M
 
replicate_do_db = dns
 
server-id = 13372
 
skip-external-locking
 
socket = /var/run/mysqld/mysqld.sock
 
ssl = false
 
ssl-ca = /etc/mysql/cacert.pem
 
ssl-cert = /etc/mysql/server-cert.pem
 
ssl-key = /etc/mysql/server-key.pem
 
thread_cache_size = 8
 
thread_stack = 256K
 
tmpdir = /tmp
 
user = mysql

Comment by Elena Stepanova [ 2018-10-04 ]

The code doesn't specify what is actually being run. We still need a working example which would demonstrate the memory leak on the server side.
Also, it's unclear from the description what you mean by "upgraded version of mysql". What is "mysql" in this context? MariaDB server? libmysqlclient? mysql command line client?

Generated at Thu Feb 08 08:34:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.