Server Monitoring and Performance Optimization

What should I monitor on a hosting server?

Monitor what visitors see from outside, plus the resources that run out first on a hosting server: CPU and disk I/O, memory, disk space and inodes, the database, the mail queue and the services themselves. Thresholds come from your baseline, so the table describes what to watch and not fixed numbers.

Who gets the alert, and how?

Each alert goes to a named person through a channel that still works when the server is down, and its urgency decides whether it interrupts them.

• Urgent. Site down, disk nearly full, mail queue exploding. A phone push or SMS to whoever is on duty.
• Warning. A trend toward a limit. An email or chat message to read in working hours.
• Digest. Slow query counts and resource trends in a weekly summary.

Never route alerts through the server that may be failing, because Exim on a dead machine cannot report its own death. I test routing by firing each alert on purpose, for example by stopping a non-critical service. An alert nobody acts on gets removed, since constant noise teaches people to ignore the one that matters. For backup and cron jobs, the heartbeat checks in the table cover the failure that produces no error at all: the job that never ran.

In what order should I tune a slow server?

Tune in a fixed order: baseline, find the bottleneck, change one thing, measure again. Skipping a step usually moves the problem somewhere else.

1. Baseline. Record load, IO wait, memory, slow query count and response times for a few key URLs, at a quiet time and at a busy one.
2. Find the bottleneck. Ask which resource saturates first. These commands show it.
3. Change one thing. One setting, with a rollback note.
4. Measure again under comparable load, then keep or revert the change on the evidence.

uptime
vmstat 5 5
iostat -x 5 3
ps -eo user,pcpu,pmem,comm --sort=-pcpu | head

How do I tune the web server and PHP-FPM?

Size PHP-FPM workers to the memory you actually have, not the traffic you hope for, then check the web server and OPcache against measurements.

• PHP-FPM workers. Set pm.max_children from the RAM reserved for PHP divided by average memory per worker. Too high pushes the server into swap. Too low queues requests, and the FPM log then reports that the pool reached pm.max_children. Use pm.max_requests to recycle leaking workers and request_slowlog_timeout to catch slow scripts.
• Web server. On Apache, I use the event MPM with PHP-FPM and tune keep-alive and connection limits from the access logs. LiteSpeed has its own settings, which are tuned the same way, from measurements.
• OPcache. Make opcache.memory_consumption and opcache.max_accelerated_files large enough that the cache never fills. opcache_get_status() shows the hit rate and whether it ran out, because scripts that do not fit are recompiled on every request.

How do I tune MySQL or MariaDB?

Find the slow queries first and size the buffer pool second, because most database slowness comes from queries and missing indexes, not server variables.

I enable the slow query log (slow_query_log and long_query_time) for a representative period, then run EXPLAIN on the worst queries and fix the query or add an index. For InnoDB, innodb_buffer_pool_size should fit the working set while leaving memory for PHP-FPM and the operating system. Raising max_connections to hide a connection leak only moves the failure. Scripts such as mysqltuner give hints that I treat as questions to test and not as rules. I try variables live with SET GLOBAL, measure, and only then write them to the config file.

When does object caching help, and how do I find a noisy neighbor?

Object caching helps dynamic sites that repeat the same database queries, and a noisy neighbor is one account using most of a shared server's CPU or disk. You find both by measuring.

Redis or Memcached keep repeated query results in memory. WordPress benefits through a persistent object cache plugin, while a static site gains nothing. On shared servers each account needs its own cache instance, or a separate prefix and authentication, so accounts cannot read each other's data. To find a noisy neighbor, I total CPU and memory per user from the process list, then read the busiest URLs from that account's logs (on EasyApache 4 the domain logs sit under /etc/apache2/logs/domlogs). Common culprits are constant wp-cron.php calls, xmlrpc.php floods and bots crawling search pages. The fixes are caching, rate limits, bot rules and per-account PHP-FPM limits. Where hard per-account CPU, memory and I/O caps are required, commercial isolation software such as CloudLinux is an option.

What I will not promise about performance

I do not promise speed-up percentages, uptime figures or benchmark scores, because they depend on your application, traffic and hardware. I report what I measured before and after on your server. If the baseline shows the machine is truly out of CPU, memory or disk, I recommend more capacity, and I do not work on hardware faults. Monitoring is typically in place within a day or two, with tuning time depending on the findings. I quote a fixed price or bill $55 to $65 per hour. Related reading covers the first-day cPanel settings, log review under hardening, backup tests and WHMCS support and maintenance.