Understanding Linux Swap Usage Despite Available Memory: Optimization for MySQL Servers


2 views

Many sysadmins encounter this puzzling scenario where a Linux server actively uses swap space despite having ample free RAM. Let's examine the technical details from your server stats:

Memory Usage: 29.53% (4.8GB of 16.25GB)
Swap Usage: 10.52% (220MB of 2GB)
CPU Load: 2.19 (8 CPUs)
MySQL CPU: 160%+

Contrary to popular belief, the Linux kernel doesn't wait until memory is exhausted to start using swap. The kernel employs sophisticated algorithms to proactively:

  • Move infrequently used memory pages to swap (vm.swappiness)
  • Maintain free memory for sudden demands
  • Cache filesystem operations in unused RAM

Your MySQL process consuming 160% CPU suggests potential issues. Check these key metrics:

# Check InnoDB buffer pool usage
SHOW ENGINE INNODB STATUS\G

# Examine active threads
SHOW PROCESSLIST;

# Monitor temporary tables
SHOW STATUS LIKE 'Created_tmp%';

Here's a comprehensive tuning approach:

# Adjust swappiness (default 60, try 10 for database servers)
echo 10 > /proc/sys/vm/swappiness

# MySQL configuration optimization (my.cnf)
[mysqld]
innodb_buffer_pool_size = 8G  # 50-70% of total RAM
innodb_log_file_size = 256M
innodb_flush_method = O_DIRECT
tmp_table_size = 64M
max_heap_table_size = 64M

Use these tools to investigate further:

# Identify memory-hungry processes
ps aux --sort=-%mem | head -10

# Detailed memory breakdown
cat /proc/meminfo

# Page cache pressure
vmstat 1 5

# Swap activity monitoring
sar -W 1 5

Monitor these warning signs:

  • Consistent si/so (swap in/out) in vmstat
  • High major page faults
  • MySQL performance degradation
  • Swappiness above your configured threshold

Remember that some swap usage is normal and can actually improve performance by allowing the kernel to optimize memory allocation. The key is monitoring the patterns rather than the absolute numbers.


Many system administrators notice their Linux servers actively using swap space even when 50-70% of physical RAM remains free. This behavior isn't a bug - it's a deliberate memory management strategy called swapiness.

# Check current swappiness value
cat /proc/sys/vm/swappiness
# Typical default: 60 (range 0-100)

The Linux kernel prioritizes keeping active memory in RAM while moving inactive pages to swap. This creates breathing room for:

  • Sudden memory spikes
  • Disk caching needs
  • Memory fragmentation prevention

Your 160% CPU usage likely indicates:

# Identify problematic queries
SHOW FULL PROCESSLIST;
# Check for table scans
EXPLAIN [your_query];
# Monitor InnoDB status
SHOW ENGINE INNODB STATUS;

For memory management:

# Temporarily adjust swappiness
sudo sysctl vm.swappiness=10

# Permanently modify (add to /etc/sysctl.conf)
vm.swappiness = 10
vm.vfs_cache_pressure = 50

For MySQL optimization:

# Key InnoDB parameters to review
innodb_buffer_pool_size = 4G  # 50-70% of available RAM
innodb_log_file_size = 256M
innodb_flush_method = O_DIRECT

Monitor these metrics:

vmstat 1 5  # Check si/so (swap in/out)
iostat -x 1 # Disk I/O pressure
dmesg | grep oom # Out-of-memory events

Here's how I optimized a similar LAMP stack:

#!/bin/bash
# Set optimal parameters
echo 10 > /proc/sys/vm/swappiness
echo "vm.swappiness=10" >> /etc/sysctl.conf

# MySQL config (adjust based on RAM)
sed -i '/innodb_buffer_pool_size/s/=.*/=4G/' /etc/mysql/my.cnf
systemctl restart mysql

# Verify improvements
free -h && mysqladmin variables | grep pool_size