Tuning MariaDB 10.11 for a 42 GB Shared WordPress Server

A shared hosting server with 16 CPU cores and 42 GiB of RAM runs mostly WordPress sites. The obvious temptation is to assign most memory to MariaDB, raise every cache, and increase max_connections. On a cPanel host, that can cause a worse outage: PHP workers, LiteSpeed or Apache, mail, backup compression, malware scanning, and the kernel all share the same memory.

The correct baseline is deliberately conservative. Give InnoDB a useful cache, keep per-connection buffers small, cap concurrency at a number the host can survive, enable evidence collection, and change one group of variables at a time.

Confirm the Supported Platform

cPanel’s current supported database matrix lists MariaDB 10.11 for AlmaLinux and CloudLinux 8/9 and identifies it as the default on uncustomized current installations. cPanel’s upgrade interface applies vendor patch releases automatically after a version is selected.

Before tuning, capture:

mariadb --version
uname -r
free -h
lsblk -o NAME,TYPE,SIZE,ROTA,MOUNTPOINTS
mariadb -e "SHOW GLOBAL VARIABLES"
mariadb -e "SHOW GLOBAL STATUS"

Also record cPanel, web-server, PHP handler, database size, storage controller, filesystem, and whether CloudLinux MySQL Governor is active. Governor changes how per-account load should be interpreted.

Do not combine a major MariaDB upgrade, filesystem change, and tuning deployment in one maintenance window.

Establish a 24-Hour Baseline

Collect at least one normal business day and one busy period:

• Peak Threads_connected and Threads_running.
• Max_used_connections.
• Host free/available memory and swap activity.
• InnoDB buffer-pool reads versus logical read requests.
• Dirty pages and checkpoint pressure.
• Temporary tables created on disk.
• Opened tables and table-cache misses.
• Slow-query count and top query patterns.
• Storage latency and IOPS during backups.

MariaDB’s Performance Schema can provide low-level workload evidence, while the slow query log identifies statements that need indexes or application changes. Performance Schema has overhead and instrumentation choices; do not enable every consumer permanently without measuring it.

Memory Budget for a Shared Host

The server has 42 GiB, but MariaDB is not dedicated. Reserve memory for:

• Kernel, filesystem cache, and ZFS/other storage layers if present.
• Web server and PHP workers.
• Mail, DNS, cPanel services, security scanner, and monitoring.
• Backup creation and compression spikes.
• Unexpected traffic bursts.

Start innodb_buffer_pool_size at 16 GiB. This is large enough to cache common WordPress tables while leaving substantial headroom. If 24-hour measurements show no swap, high available memory, and a database working set larger than the pool, test 18–20 GiB. Do not jump directly to 30 GiB on a multi-service host.

MariaDB’s own performance guide often assumes a dedicated database server. That assumption does not apply here.

A Conservative Initial Configuration

Use this as a reviewable starting point, not a universal final answer:

[mysqld]
innodb_buffer_pool_size=16G

# SSD/NVMe: avoid flushing adjacent pages as if storage were a spinning disk.
innodb_flush_neighbors=0

# Keep concurrency survivable; revise from Max_used_connections and RAM tests.
max_connections=200
thread_cache_size=100

# Moderate metadata caches for many WordPress schemas.
table_open_cache=4000
table_definition_cache=4000

# These buffers can be allocated per connection; keep them bounded.
tmp_table_size=64M
max_heap_table_size=64M

# Evidence for query-level optimization.
slow_query_log=ON
long_query_time=1
min_examined_row_limit=100

Review current values first. If the server already has lower, evidence-backed limits or cPanel-managed settings, explain every change in the maintenance record.

tmp_table_size and max_heap_table_size do not reserve only one global 64 MiB block; memory behavior depends on active connections and queries. Do not set them to hundreds of megabytes on a 200-connection shared server.

Likewise, avoid globally inflating sort_buffer_size, join_buffer_size, read_buffer_size, and read_rnd_buffer_size. They are workload/per-connection buffers. A missing index should be fixed as a query/index problem, not hidden behind a large join buffer for every tenant.

Keep the 10.11 Flush Default Unless Evidence Disagrees

MariaDB’s current InnoDB flush-method documentation says O_DIRECT has been the Unix default since MariaDB 10.6. It avoids double-caching InnoDB data in both the buffer pool and filesystem cache.

Do not add innodb_flush_method=O_DIRECT merely because an old tuning guide includes it; confirm the effective default. Do not use unsafe no-sync settings. Crash safety and tested backups are more important than a synthetic write benchmark.

For innodb_io_capacity, measure storage rather than copying a number labeled “NVMe.” MariaDB defines it in data pages per second and notes that modern page flushing has specific scope and interactions. A virtual NVMe device backed by a busy RAID array is not equivalent to local enterprise NVMe.

Start with the current default, observe checkpoint and dirty-page behavior, benchmark the actual datastore, then adjust gradually. Never advertise the drive’s peak marketing IOPS as a safe database flush rate.

Connection Limits Must Match PHP Concurrency

max_connections=200 is a survival cap for the initial design, not a target. Count all potential PHP workers across versions and accounts, monitoring connections, cron jobs, backup tools, and administrative sessions.

If Threads_running remains low while Threads_connected spikes, the issue may be idle connection behavior. If both rise and the host saturates, increasing the cap admits more work into an already overloaded server.

MariaDB recommends considering its thread pool when there are more than roughly 128 simultaneously running fast queries. A WordPress host with 200 possible connections but only 15 running queries does not meet that condition. Test thread_handling=pool_of_threads in staging before enabling it globally; plugin workloads, backups, and administrative operations may react differently.

Use CloudLinux limits, PHP-FPM/LSAPI worker controls, and caching to prevent one account from consuming the entire database connection budget.

Optimize WordPress Above the Database Layer

MariaDB tuning cannot repair:

• A plugin executing the same uncached query hundreds of times.
• Autoloaded options measured in megabytes.
• Missing indexes on plugin tables.
• WP-Cron storms across many sites.
• Bots bypassing page cache.
• Object-cache misuse or very low cache hit rates.
• Backup jobs starting simultaneously.

Group slow queries with mariadb-dumpslow, which MariaDB documents as its slow-log summarizer. Use sanitized examples and EXPLAIN on a staging copy before adding indexes to plugin-owned tables. An update can overwrite an unsupported schema modification.

Full-page caching often removes more database work than another buffer adjustment. Persistent object caching can help repeated object lookups, but it needs per-site isolation, memory limits, monitoring, and plugin compatibility.

Deploy Through a Controlled Maintenance Window

1. Take a full database backup and verify that it can be read.
2. Save /etc/my.cnf and included configuration files.
3. Record current variables and status counters.
4. Add only the reviewed settings.
5. Validate how MariaDB resolves the configuration with my_print_defaults mysqld.
6. Use cPanel’s supported service controls to restart MariaDB.
7. Confirm mariadb-admin ping and inspect the MariaDB error log.
8. Re-run SHOW GLOBAL VARIABLES to prove that each value took effect.
9. Test several WordPress sites, wp-admin, cron, email-related plugins, and backups.
10. Monitor memory, swap, connection peaks, and disk latency through the next busy period.

cPanel’s Edit SQL Configuration documentation warns that changes through the interface restart the database service. Treat even a “Save” as a maintenance event.

Review After One Week

Use status deltas, not counters collected since an unknown restart. The review should answer:

• Did swap remain at zero during traffic and backup peaks?
• Did the buffer-pool physical read rate improve?
• Did disk temporary tables decline without memory spikes?
• Did slow-query volume or total time fall?
• Is Max_used_connections safely below the cap?
• Are table cache misses material?
• Did page latency or checkout/admin response improve?

If memory is idle and the active dataset misses the buffer pool, increase it by 2 GiB and measure again. If the host swaps during backups, reduce it or reschedule resource-heavy jobs. If one query dominates, fix that query instead of allocating more server memory.

Conclusion

For a 16-core, 42 GiB shared WordPress host, a 16 GiB InnoDB buffer pool, bounded connection and table caches, SSD-aware neighbor flushing, and a usable slow-query log form a safe initial MariaDB 10.11 baseline.

The final configuration must come from the host’s connection peaks, query patterns, memory pressure, and real storage latency. Preserve headroom for PHP and backups, keep per-connection buffers modest, and use cPanel’s supported management path. Shared hosting performance improves when database tuning and tenant concurrency controls are designed together.

Related Guides

Database tuning should be separated from web-stack faults. Use our procedure for diagnosing WordPress PHP 8.3 and ModSecurity 403 errors, and consult the AccelerateWP installation troubleshooting guide when the optimization layer itself fails to provision.