Yes, but we recently we have reduced it match with the # of vCPUs and the situation remains the same.

I got a small reproducible case as in the attached file:

1. A table called t2 is created.
2. An insert w/ 10mil records via the stored procedure InsertIntoLknmT2_bind_savept() caused increase in node 2's memory utilization, whenever the SP was executed for the first & second time.
3. An SP Update_LknmT2_bind_savept was executed twice. Each time, there was rapid increase in memory utilization at node 2, during commit.
4. An SP Update_LknmT2_bind was executed twice. Each time, there was rapid increase in memory utilization at node 2, during commit.

It appears that the committing after running large batch of INSERT or UPDATE can lead to such situation, regardless of the presence of savepoint / release savepoint.

Thanks and best regards,

Lawrence

Investigation-2025-04-03.txt

In the previously attached file, the same insert / update is executed 10mil times, in a single transaction. The SQLs are written using bind variable. In this situation, will the memory used to parse the SQL be allocated for the first SQL, and re-used for the rest of SQLs within that same transaction, or will the memory used to parse the SQL be multiplied by 10mil times, since they are in the same transaction?

I raise the above query because it can be observed that there is a sharp rise in memory utilization, even though only a single INSERT/UPDATE SQL skeleton is used.

LawrenceMan I would not recommend inserting 10 million rows in a single transaction. From node2 point of view it will be 10 million events to be executed and every event requires memory. If you send those inserts as a single transaction and of you have more than one applier threads as these inserts do not really conflict more than one applier thread will start allocating memory for events. From node2 point of view it does not matter do you have savepoints or prepared transactions. I do not know about node1 point of view.

Hi Jan,

Thanks for your reply.

The program was meant to reproduce the case more obviously for illustration only. If the # of records committed in a batch is reduced to 100K (the actual order of magnitude in my customer's case), the situation was similar but the increase is less significant, and still requires periodic restart of MariaDB at node 2 to release the memory.

Is MariaDB supposedly able to handle 100K records transaction without continuous memory growth / leak at node 2? Or is it necessary to break down the transaction into still smaller chunks?

Thanks and best regards,

Lawrence