[MDEV-31520] Memory leak in 10.5.19 and 10.5.20 Created: 2023-06-21  Updated: 2023-07-30  Resolved: 2023-07-30

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.5.19, 10.5.20, 10.5.21
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Brian Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: Memory_leak, crash, regression
Environment:

CentOS 7.9.2009, 64 GB RAM, only MariaDB running on them.

Attachments: Text File memleak-results.txt    

 Description   

We had two fresh installs (one with 10.5.20 and one with 10.5.21) and they both showed signs of a memory leak right away. The server with 10.5.20 installed was going from restart to consuming all available RAM in about 2 hours, linearly, while 10.5.21 was taking about 10 hours. The server using the RAM the fastest had about 3x the query load on it.

We downgraded both servers to 10.5.19 because we have several others on that version that aren't showing memory leaks. These are all sharded servers so they all have similar data and queries happening on them.

The one downgraded from 10.5.21 to 10.5.19 (which had the fastest memory leak before) is now stable, without increasing memory.

However, the one downgraded from 10.5.20 to 10.5.19 continues to have a memory leak and is consuming all of the RAM on the server every 8 hours or so.

The results of `/usr/share/bcc/tools/memleak -o 16000 -T 5 -p 36782` from the server still showing memory leaks is attached. I didn't know about that tool when they were on 10.5.20 and 10.5.21 so I don't have output for those versions.

 Comments   
Comment by Sergei Golubchik [ 2023-07-02 ]

do you have debuginfo packages installed? Those

    [unknown] [mariadbd]
 
    [unknown] [mariadbd]

lines don't allow to see where the allocations are coming from.

could you try whether flush tables help? it likely won't, but it's easy to to try and know for sure.

All top 5 largest allocations come from opening tables for queries on INFORMATION_SCHEMA.TABLES. Do you have lots of tables? Unfortunately, the exact location of the leak is hidden behind these [unknown] lines.

Generated at Thu Feb 08 10:24:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.