0

I have a backend server with 1G RAM for my HTTP server and my MariaDB.

I noticed the database keeps getting killed by OOM once or twice a day. Most of the time the OOM is triggered by the HTTP server, but not always.

I tried limiting innodb_buffer_pool_size lower and lower, it is at 64M at this moment, but the process is still taking 40% to 70% of the server's memory.

How do I find the reason of this memory usage? It appears to be some kind of memory leak, because it keeps increasing throughout the day and not releasing much of it.

The database usually starts consuming about 7% to 9% of memory usage.

MariaDB version 10.5

Improve this question
10
  • There is also code and other tables. Where's the config I asked for?
    – Rick James
    Aug 3 at 16:08
  • Look at this answer: dba.stackexchange.com/a/264585/7895
    – Kondybas
    Aug 3 at 20:39
  • @RickJames Global status: pastebin.com/MPjEvueX What are the relevant variables you wanna see?
    – ydrezende
    Aug 4 at 2:35
  • I checked the link provided by @Kondybas and got some useful information with the MysqlTuner. It shows me the following: [--] Total buffers: 298.0M global + 256.6M per thread (40 max threads) [--] P_S Max memory usage: 0B [--] Galera GCache Max memory usage: 0B [OK] Maximum reached memory usage: 554.6M (58.20% of installed RAM) [!!] Maximum possible memory usage: 10.3G (1108.44% of installed RAM) [!!] Overall possible memory usage with other process exceeded memory I tried tinkering with some variables but none of them lowered the size of the thread buffer. I set max threads to 40
    – ydrezende
    Aug 4 at 2:38
  • I managed to lower my thread size by lowering the max_allowed_packet... It was set to 256M because mysqldump always failed in the middle of the backup... But the mysqldump value is set to it's own section now. With that I managed to bring the value down to this: [OK] Maximum possible memory usage: 623.6M (65.45% of installed RAM) I will check how it will behaves for this next day and post the answer in case of a success. Thank you!
    – ydrezende
    Aug 4 at 3:07

1 Answer 1

Reset to default
0

Thanks to @Kondybas and @RickJames!

The database survived the entirety of the day.

The main issue was the max_allowed_packet that was set too high and it increases the buffer size of each of the connection threads.

After using MysqlTuner I was able to tweak the variables until I got a report showing max usage of about 60% of the RAM, I think a maximum usage of 50% would be ideal but the buffers are already set too low and we store pretty large blobs on this database, so I think 32M of max_allowed_packet is the lowest I can use.

I lowered max_connections to 10 as well.

Hope this helps other people.

Improve this answer
1
  • Additional information request, please. #cores on server, Any SSD or NVME devices on MySQL Host server? Post TEXT data on justpaste.it and share the links. From your SSH login root, Text results of: A) SELECT COUNT(*) FROM information_schema.tables; B) SHOW GLOBAL STATUS; after minimum 24 hours UPTIME C) SHOW GLOBAL VARIABLES; D) SHOW FULL PROCESSLIST; E) STATUS; not SHOW STATUS, just STATUS; F) complete www.MySQLTuner.pl (perl) report or similar. for server workload tuning analysis to provide performance enhancing suggestions.
    – Wilson Hauck
    Aug 6 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.