How to fix ERROR 1037: Out of memory; restart server in MySQL

MySQLINTERMEDIATECRITICALUpdated Jul 28, 2026· 127 views

ERROR 1037 indicates MySQL has exhausted available memory, but the underlying cause can be insufficient RAM, too many file handles, corrupted table files, or memory buffer misconfiguration. This guide covers diagnosis and fixes.

Quick fix

Fixes 1037

free -h
# Output shows Mem and Swap usage

cat /proc/meminfo | grep -E 'MemFree|SwapFree'

# Check swap configuration
swapon --show
  1. Check available system memory and swap space
  2. Check system file handle limits
  3. Review and optimize MySQL memory buffer settings
  4. Check for corrupted table files
mysql — error
free -h
# Output shows Mem and Swap usage
cat /proc/meminfo | grep -E 'MemFree|SwapFree'
# Check swap configuration
swapon --show
ERROR 1037: Out of memory; restart server

What this error means

MySQL ERROR 1037 (SQLSTATE HY001) occurs when the MySQL server cannot allocate memory for an operation. The error message often specifies the number of bytes needed (e.g., "needed 65528 bytes"). However, this error can be misleading—the actual root cause is frequently not memory exhaustion but rather too many file handles open, corrupted .frm or .par files, or queries consuming excessive temporary table memory. The server may also return this error when system swap space is unavailable or when memory buffers are misconfigured relative to available system RAM.

Typical symptoms

  • MySQL queries fail with "Out of memory; restart server" error
  • Error appears intermittently or consistently depending on query complexity
  • Server continues running but specific operations (ORDER BY, GROUP BY, JOIN) fail
  • Error persists even when system appears to have free RAM available
  • Errors occur during ALTER TABLE, REBUILD PARTITION, or other DDL operations
  • Replication fails with ERROR 1037 on secondary servers

Common causes

  1. Insufficient physical RAM or swap space on the server
  2. Too many file handles open (misleading error message when ulimit is exceeded)
  3. Memory buffer settings (innodb_buffer_pool_size, sort_buffer_size, etc.) configured too large for available RAM
  4. Corrupted .frm (table definition) or .par (partition definition) files
  5. Complex queries with large result sets using temporary tables in memory
  6. Per-thread buffer settings multiplied by max_connections exceed available memory
  7. Memory leaks in older MySQL versions
  8. Replication with mismatched cluster sizing between primary and secondary nodes

How to fix "ERROR 1037: Out of memory; restart server"

1Check available system memory and swap space

First, verify that your system actually has sufficient free memory and swap configured.

Linux:

bash
free -h
# Output shows Mem and Swap usage

cat /proc/meminfo | grep -E 'MemFree|SwapFree'

# Check swap configuration
swapon --show

macOS:

bash
vm_stat
# Shows free, inactive, and wired memory pages

# Check swap usage
ls -lh /var/vm/swap*

If swap space is very low or zero, add swap or increase it before proceeding.

2Check system file handle limits

Too many open file handles is a common cause of ERROR 1037. Check if MySQL is hitting the system limit.

Check current limits:

bash
# Current process limits
ulimit -n
# Should typically be 1024 or higher

# System-wide limits
cat /proc/sys/fs/file-max
cat /proc/sys/fs/file-nr

Increase file handle limits:

Edit /etc/security/limits.conf and add:

ini
mysql soft nofile 65536
mysql hard nofile 65536
mysql soft nproc 65536
mysql hard nproc 65536

Then restart MySQL:

bash
sudo systemctl restart mysql
3Review and optimize MySQL memory buffer settings

Memory buffers configured too large for available RAM is a frequent cause. Review your MySQL configuration file.

Locate your MySQL config:

bash
mysql --help | grep 'Default options' -A 1
# Usually /etc/mysql/mysql.cnf, /etc/mysql/my.cnf, or /etc/my.cnf

Check current memory settings:

sql
SHOW VARIABLES LIKE '%buffer%';
SHOW VARIABLES LIKE '%cache%';
SHOW VARIABLES LIKE '%pool%';

Key settings to review and adjust:

1. InnoDB Buffer Pool (largest consumer):

ini
# Rule of thumb: 50-80% of available RAM, never more than physical RAM
innodb_buffer_pool_size = 1G

2. Per-thread buffers (multiply by max_connections):

ini
sort_buffer_size = 2M          # Used for ORDER BY, GROUP BY
read_buffer_size = 1M
read_rnd_buffer_size = 1M
join_buffer_size = 1M
tmp_table_size = 64M
max_heap_table_size = 64M

3. Total memory estimate:

bash
total = innodb_buffer_pool_size +
        (sort_buffer_size * max_connections) +
        (read_buffer_size * max_connections) +
        (join_buffer_size * max_connections) +
        (key_buffer_size) +
        (query_cache_size) +
        ~500MB for OS and other overhead

Apply changes:

Edit your MySQL config file and adjust values, then restart:

bash
sudo systemctl restart mysql
4Check for corrupted table files

Corrupted .frm or .par files can trigger ERROR 1037 even when memory is available.

Check for corrupted tables:

bash
# Navigate to MySQL data directory (usually /var/lib/mysql)
cd /var/lib/mysql

# Check for missing or corrupted files
# .frm = table definition
# .ibd = InnoDB data file (if using InnoDB)
# .par = partition definition

# Look for incomplete files or permission issues
ls -la your_database/ | grep -E '\.(frm|par)$'

Repair tables:

sql
-- Connect to MySQL and repair the suspected table
REPAIR TABLE table_name;

-- For InnoDB, use CHECK and OPTIMIZE
CHECK TABLE table_name;
OPTIMIZE TABLE table_name;

-- If that fails, use innochecksum (InnoDB only)
-- Stop MySQL first

For missing .par files (partitioned tables):

The error "missing .par file" now returns a more descriptive message in MySQL 5.1.48+. If you have an older version, consider upgrading.

5Optimize problematic queries

Some queries consume excessive temporary table memory and trigger ERROR 1037.

Identify problematic queries:

sql
-- Enable slow query log if not already enabled
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

-- Or check the error log for patterns
SHOW VARIABLES LIKE 'log_error';

Optimize queries that use ORDER BY or GROUP BY:

Instead of:

sql
SELECT * FROM large_table
WHERE status = 'active'
ORDER BY created_at DESC
LIMIT 1000;

Use:

sql
-- Add indexes to avoid full scans and temporary table sorts
CREATE INDEX idx_status_created ON large_table(status, created_at DESC);

-- Use LIMIT to reduce result set
SELECT id, status, created_at FROM large_table
WHERE status = 'active'
ORDER BY created_at DESC
LIMIT 100;

-- For very large aggregations, consider materialized views or caching
SELECT status, COUNT(*) FROM large_table
GROUP BY status;

Analyze query execution:

sql
EXPLAIN FORMAT=JSON SELECT ... \G
-- Look for "Using temporary", "Using filesort" indicators
6Adjust max_connections if necessary

Too many connections multiplies per-thread buffer usage. Reduce max_connections if not needed.

Check current setting:

sql
SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';

Reduce if necessary:

Edit your MySQL config:

ini
# Default is often 151, reduce to match actual concurrent connections needed
max_connections = 100

# Also reduce thread cache to free memory
thread_cache_size = 8

Then restart MySQL.

7Restart MySQL as a last resort

If you've made configuration changes or need to clear memory allocations immediately:

bash
# Linux/Unix
sudo systemctl restart mysql

# Or using service
sudo service mysql restart

# Check it restarted successfully
sudo systemctl status mysql

# Or monitor the log
tail -f /var/log/mysql/error.log

After restart, monitor for the error recurring. If it persists, the root cause is not temporary memory fragmentation.

Advanced notes

For replication environments: Compare cluster sizing (Storage, Memory, CPU) between primary and secondary servers. A secondary with less memory will fail first.

Linux kernel memory overcommit: Check vm.overcommit_memory setting. A value of 1 allows memory overcommit, potentially causing OOM errors later.

bash
cat /proc/sys/vm/overcommit_memory
# 0 = heuristic, 1 = always allow, 2 = never allow

InnoDB background threads: Even at idle, InnoDB consumes memory. Multiple background threads (flushing, IO threads) each allocate buffers. Monitor with SHOW ENGINE INNODB STATUS;\G

Temporary table memory: Temporary tables created by queries (ORDER BY without index, large GROUP BY) first use memory (tmp_table_size), then spill to disk. Increase tmp_table_size carefully or add indexes to avoid temporary tables.

MySQL version: Older versions (pre-5.1.48) return ERROR 1037 for missing partition files instead of descriptive messages. Upgrade if running very old versions.

Frequently asked questions

What does "1037" mean?
MySQL ERROR 1037 (SQLSTATE HY001) occurs when the MySQL server cannot allocate memory for an operation. , "needed 65528 bytes"). par files, or queries consuming excessive temporary table memory.
How do I fix "1037"?
ERROR 1037 indicates MySQL has exhausted available memory, but the underlying cause can be insufficient RAM, too many file handles, corrupted table files, or memory buffer misconfiguration. This guide covers diagnosis and fixes.
What causes "1037"?
Insufficient physical RAM or swap space on the server Too many file handles open (misleading error message when ulimit is exceeded) Memory buffer settings (innodb_buffer_pool_size, sort_buffer_size, etc.) configured too large for available RAM
Is the "1037" error serious?
Yes. This is a critical-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading