ERPNext Running Slow: How a MariaDB Memory Leak Brought Down a 500-Employee Operation

A Mumbai jewellery manufacturer with over 500 employees started noticing ERPNext slowing down. Pages that used to load in 2 seconds were taking 15. Inventory lookups were timing out. The warehouse floor was waiting on screens.

The server was Ubuntu 22.04.4 LTS, kernel 6.8.0-101-generic. ERPNext on Frappe. MariaDB as the database backend. The server had not changed. No new deployments. No configuration changes anyone could remember.

Root cause: MariaDB’s InnoDB buffer pool had grown to consume nearly all available RAM. The OS was swapping. Every database query was slow because the system was paging memory to disk on every request.

What a MariaDB memory leak looks like on an ERPNext server

Check free memory first:

free -h

On the affected server, available memory was under 200MB on a 16GB machine. Swap was active and growing.

Check what is consuming memory:

ps aux --sort=-%mem | head -10

MariaDB was at the top. Check the InnoDB buffer pool size currently allocated:

mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Then check actual runtime memory usage:

mysql -u root -p -e "SELECT * FROM information_schema.INNODB_BUFFER_POOL_STATS\G" | grep -i "pages\|size"

Check if swap is being used actively:

vmstat 1 5

Non-zero si and so columns in vmstat output confirm the system is swapping — reading and writing memory to disk. On an ERPNext server this explains exactly the slowdown pattern: intermittent, getting worse over time, no obvious trigger.

The fix: MariaDB buffer pool tuning

The default MariaDB configuration is not tuned for an ERPNext production server. The InnoDB buffer pool defaults can grow well beyond what the server can sustain alongside Frappe’s Python workers, Redis, and the OS itself.

1. Set innodb_buffer_pool_size explicitly

Edit /etc/mysql/mariadb.conf.d/50-server.cnf or /etc/mysql/my.cnf:

[mysqld]
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 2
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT

The rule of thumb: set innodb_buffer_pool_size to 50-70% of total RAM, leaving enough headroom for Frappe workers, Redis, and the OS. On a 16GB server, 8-10GB is reasonable. On the AR Gold server, 2GB was set initially to stabilise the system, with the intention to tune upward after monitoring RAM usage under normal load.

2. Add memory limits for MariaDB

[mysqld]
performance_schema = OFF
key_buffer_size = 32M
max_connections = 100
thread_stack = 256K
thread_cache_size = 8

Disabling performance_schema on a production ERPNext server that does not need query profiling saves significant memory. On the affected server this freed approximately 400MB immediately.

3. Restart MariaDB and verify

systemctl restart mariadb
free -h
mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Watch memory over the next 30 minutes:

watch -n 30 'free -h && echo "---" && vmstat 1 3'

Swap usage should drop as the OS reclaims pages. ERPNext response times should return to normal within minutes of the restart.

Why this happens on ERPNext servers specifically

ERPNext is a memory-hungry stack. Frappe runs multiple gunicorn workers. Redis handles caching and background jobs. MariaDB handles all transactional data. On a server sized for initial deployment, the combined memory footprint grows as the business grows — more users, more transactions, more background jobs.

MariaDB’s InnoDB buffer pool grows to cache frequently accessed data. On a default configuration with no explicit ceiling, it expands to fill available memory. As the buffer pool grows, it squeezes the memory available for Frappe workers and Redis. The OS starts swapping. Everything slows down.

The server at AR Gold had been running for over a year without memory tuning. The business had grown. Transaction volume had increased. The default MariaDB configuration that was acceptable at initial deployment was no longer adequate for current load.

This is not a one-time fix. Memory configuration needs to be reviewed as the business grows. A server that runs well at 50 users may need retuning at 200.

How to prevent this

Set up memory monitoring. Nagios or a cron-based check that alerts when available RAM drops below 20% gives you time to tune before the server starts swapping:

# Alert when available memory drops below 2GB (adjust threshold for your server)
0 * * * * free -m | awk '/^Mem:/ { if ($7 < 2048) print "Low memory: " $7 "MB available" }' | mail -s "Memory warning: $(hostname)" arun@avservices.in

Review MariaDB memory usage monthly as part of routine maintenance. As transaction volume grows, the buffer pool configuration needs to grow with it — or the server needs more RAM.

AV Services manages Linux servers running ERPNext and other ERP systems for businesses in Mumbai on monthly retainer. Memory monitoring, MariaDB tuning, and performance reviews are part of every managed server. See the Linux server management for ERP systems page or start with a free Linux server audit.