Skip to main content

Connection Tuning

The database connection layer sits between PHP workers (PHP-FPM/LSAPI) and the MySQL/MariaDB engine. If PHP concurrency is higher than what the database is configured to accept, requests fail with connection errors. If the database allows too many connections for the available RAM, the server becomes unstable.

Quick Summary
  • Align max_connections with your PHP worker pool (pm.max_children / LSAPI children).
  • Reduce idle connection lifetime with wait_timeout for typical WordPress workloads.
  • Use thread_cache_size to reduce thread creation overhead under bursts.
  • Monitor Threads_connected, Threads_running, and Max_used_connections to validate the sizing.

Core Variables & Parameter Tuning​

Connection limits are a RAM trade-off. Each connection and thread can consume memory, so raising limits without headroom can make things worse.

Variable DirectiveSafe DefaultPerformance TargetOperational Purpose
max_connections151150-300Defines the absolute total simultaneous database connections allowed dynamically across the host.
max_user_connections0 (Unlimited)60-100Defines the per-database-user limit physically preventing a single hijacked site from saturating the global matrix.
wait_timeout28800 (8 Hours)60-120Defines the exact seconds the database retains idle "sleep" connections before terminating them cleanly to save RAM.
thread_cache_size932-128Retains idle execution threads actively in RAM, bypassing the CPU overhead required to spawn fresh threads for new visitors.
open_files_limit102465535+Necessary for concurrent servers or WordPress Multisite holding thousands of custom tables open.
note

Targets vary by workload. A cache-heavy blog may be stable with fewer connections than a checkout-heavy store.

The Implementation Procedure​

Configure the core settings inside the root .cnf file systematically.

locate-mysql-configuration.sh
# Ubiquity defaults often route strictly through the MariaDB or MySQL specific directories
sudo nano /etc/mysql/my.cnf

1. Audit Current Usage & Align Limits​

Before increasing connection counts blindly, audit the specific existing PHP worker maximums (e.g., pm.max_children or lsphp_children). The database requires exactly mathematical headroom exceeding the maximum potential PHP processes.

my.cnf
[mysqld]
# Multiply the total PHP worker capacity natively by 1.25 safely to calculate proper headroom
max_connections = 250
max_user_connections = 120

# Drop idle connections to preserve RAM
wait_timeout = 90
interactive_timeout = 180

# Keep threads actively warm for WooCommerce surges safely
thread_cache_size = 64
table_open_cache = 4096
open_files_limit = 65535

2. Monitor Active Connections Safely​

Restart the database safely to instantiate the logic, then forcefully inspect the active runtime metrics directly immediately during peak traffic events accurately.

monitor-connections.sh
sudo systemctl restart mysql
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW STATUS LIKE 'Threads_running';"
mysql -e "SHOW STATUS LIKE 'Max_used_connections';"

If Threads_connected routinely approaches max_connections during business hours, you are one burst away from connection errors.

Sizing Matrix Application​

The Lean Stack Requirements

If most traffic is served from cache (Cloudflare/LSCache), database connection pressure is usually low.

  • Strategy: keep max_connections moderate and use a shorter wait_timeout.
  • Outcome: less idle memory usage.

Common Mistakes & Troubleshooting​

Configuration FailureOperational SymptomRemediation Protocol
Pool saturationError establishing a database connection appears under load.Align PHP worker counts and max_connections, and reduce slow queries.
Idle connection buildupRAM usage slowly rises due to many sleeping connections.Reduce wait_timeout and confirm application behavior isn't leaking connections.
Single Tenant LockoutIn a shared VPS hosting 10 completely isolated web properties securely, one specific site completely crashes while the other exactly 9 operate flawlessly dynamically.The specific crashed tenant exceeded the strictly enforced max_user_connections limitation locally firmly. It requires debugging completely uniquely identifying the offending script.

What's Next​