DEV Community: EniyiSunucum

Stop Hosting Client WordPress Sites in One Shared Account

EniyiSunucum — Sat, 19 Sep 2026 17:20:59 +0000

Hosting ten client sites is not the same problem as hosting one site ten times. The difference is not storage capacity or the number of domains a control panel accepts. It is the size of the failure domain: which clients are affected when one password leaks, one plugin is compromised, one PHP worker pool is exhausted, or one backup cannot be restored.

Disclosure: This technical guide was prepared with AI assistance and reviewed for accuracy and clarity by the EniyiSunucum team.

Small agencies often begin with several WordPress installations inside one shared hosting account. That can be convenient while the portfolio is small, but the model becomes harder to defend as sites accumulate revenue, personal data, email, and contractual uptime expectations. A safer design gives each client a clear security boundary, a measurable resource budget, and an independently testable recovery path.

This guide explains how to build that operating model without assuming that every agency needs to manage a fleet of virtual machines.

Begin with the failure domain

A failure domain is the set of systems that can be disrupted by one event. If every client site uses the same hosting login, filesystem owner, backup job, and PHP limits, the account itself is the failure domain.

That design creates several forms of coupling:

A compromised administrator credential can expose every site.
A vulnerable plugin may be able to read or modify neighboring files.
One traffic spike can consume the account's shared workers or I/O allowance.
A full disk can interrupt unrelated databases, logs, sessions, and email.
Restoring one client may require changing a backup that contains all clients.
Giving a contractor access to one project may expose the rest of the portfolio.

The first architectural question is therefore not “How many websites fit?” It is “Which clients can fail together, and why?”

For most agencies, the practical target is one hosting account per client or per independently managed project. This does not guarantee perfect isolation—the provider and platform still matter—but it creates a much cleaner administrative, filesystem, credential, and recovery boundary than placing every site under one account.

Give every client an explicit identity boundary

Each client environment should have its own control-panel account, system user where the platform exposes one, SFTP credentials, databases, and application secrets. Shared administrator credentials should be the exception, not the workflow.

A useful minimum standard is:

a separate hosting account for each client;
a unique WordPress administrator identity for each human operator;
a unique database user and password for each site;
separate SFTP or deployment credentials;
no password reuse between production, staging, email, and the registrar;
multi-factor authentication wherever the control plane supports it;
an access-removal checklist for staff and contractors.

This model improves incident response. If credentials for one customer are exposed, the agency can rotate that customer's secrets without scheduling a portfolio-wide outage. Audit trails also become more meaningful because actions can be attributed to a person or a project instead of a shared login.

Treat PHP capacity as a queueing problem

WordPress performance is frequently described as a CPU or cache problem. Under concurrency, it is often a queueing problem.

Every uncached dynamic request occupies a PHP worker until application code, database queries, remote API calls, and filesystem operations finish. When all workers are busy, additional requests wait. A site can therefore report modest average CPU utilization while users experience long tail latency because the worker pool is saturated or blocked.

Track at least these signals per site:

concurrent PHP workers or entry processes;
request rate and cache-hit ratio;
p50, p95, and p99 response time;
slow PHP transactions;
database query latency and connection pressure;
CPU throttling, memory pressure, and I/O wait;
the duration and frequency of WordPress cron jobs;
external service timeouts.

Avoid sizing from page views alone. Two sites with the same monthly traffic can have radically different resource profiles. A mostly cached publication may serve large volumes efficiently, while a membership site with authenticated sessions, searches, checkout requests, or personalized dashboards can generate dynamic work on nearly every request.

When comparing a WordPress hosting environment, evaluate PHP limits, web-server behavior, database access, backup tooling, and observability together. A long feature list is less useful than knowing how the platform behaves when the site's uncached concurrency rises.

Allocate a resource budget per site

An account boundary is operationally useful only when resource consumption can also be observed and controlled. Define a budget for each client based on normal load, peak load, deployment behavior, and business importance.

The budget may include:

CPU time or virtual cores;
memory;
concurrent processes;
PHP workers or entry processes;
disk throughput and IOPS;
database size and query volume;
storage growth;
backup size and execution window;
outbound email or API activity.

The objective is not to keep every graph low. It is to prevent one tenant from silently consuming the headroom needed by others. Record a healthy baseline and define a trigger for investigation—for example, repeated worker exhaustion, sustained memory pressure, a backup window that overlaps business traffic, or a p95 response time outside the client's service objective.

Resource limits should produce an escalation path, not a surprise. Decide in advance whether a constrained site will be optimized, moved to a higher account tier, separated onto a VPS or VDS, or redesigned to reduce synchronous work.

Do not confuse WordPress Multisite with hosting isolation

WordPress Multisite is an application feature for managing a network of related sites. It is not a substitute for isolating unrelated customers.

Sites in a Multisite network share a WordPress core, a database structure, plugins, themes, and a super-administrator boundary. That can be appropriate for one organization operating regional sites, a university managing departments, or a product with centrally governed tenants. It is usually a poor boundary for unrelated agency clients who need independent plugin policies, maintenance windows, credentials, billing, exports, and exit plans.

Use Multisite when shared governance is intentional. Use separate client environments when ownership and operational responsibility must remain distinct.

Make restoration the unit of backup quality

A backup is not proven because a dashboard displays a green check. It is proven when the team can restore the required data within the promised recovery time.

Define two values for every client:

Recovery Point Objective (RPO): how much recent data can be lost.
Recovery Time Objective (RTO): how long the service can remain unavailable.

Then verify that the backup design can meet them. Check database and filesystem consistency, retention, encryption, storage location, access controls, and whether the backup system is independent of the production account. A backup that an attacker can delete with the same compromised credential is a weak last line of defense.

Run scheduled restore tests to a separate environment. The test should verify more than the home page:

restore the database and files;
replace environment-specific URLs or secrets safely;
confirm administrator access;
test forms, checkout, search, and authenticated workflows;
inspect media and generated files;
validate scheduled jobs and outbound integrations;
record the elapsed time and any manual steps.

The result becomes evidence for capacity planning. If restoring a growing media library already exceeds the client's RTO, the agency has discovered the problem before an incident.

Separate staging from production

Staging should reduce deployment risk without becoming another path into production.

Use separate credentials and, where possible, a separate account or isolated environment. Do not copy live customer data into staging by default. When realistic data is required, remove or mask personal information and payment-related fields. Disable public indexing, transactional email, payment callbacks, analytics pollution, and scheduled jobs that should run only in production.

A disciplined deployment path is small and repeatable:

source-controlled themes, plugins, and configuration;
documented database migrations;
a pre-deployment backup or snapshot appropriate to the change;
a health check after deployment;
a rollback decision with a clear time limit.

Avoid using production as the first place to discover whether a plugin update changes the database, PHP requirement, cron schedule, or cache behavior.

Keep DNS, email, and certificates outside the blast radius

Website recovery frequently fails because the team focuses only on WordPress files and the database.

Document ownership and access for the domain registrar, DNS provider, certificate automation, transactional email service, and mailbox provider. Use role-based access where possible. The agency should know which assets belong to the client, which are managed on the client's behalf, and how control will be transferred at the end of the relationship.

Separating authoritative DNS and domain registration from the hosting account can preserve a recovery route when the hosting control plane is unavailable. Likewise, keeping critical operational email independent of the affected site helps the team receive alerts and coordinate during an outage.

Choose the operating model deliberately

Agencies generally choose among three models.

Individual retail hosting accounts

This offers strong commercial separation but can create administrative overhead as the portfolio grows. It works well when clients pay providers directly or require ownership of their own account from day one.

Reseller hosting

A reseller platform can give an agency one administrative view while preserving separate client accounts. It is a sensible middle ground when the agency wants account-level isolation and standard hosting operations without managing the operating system.

When evaluating a reseller hosting model, compare the number of accounts, per-site resource limits, backup and restore workflow, delegation controls, supported runtimes, and the provider's escalation process. “Unlimited” storage or traffic should never be interpreted as unlimited CPU, memory, workers, or operational support.

VPS or VDS

A virtual server provides more control over the web stack, monitoring, networking, and automation. It also transfers more responsibility to the agency: operating-system updates, security hardening, backups, service monitoring, capacity planning, and recovery testing. It is appropriate when the team can operate that layer reliably or has a managed service covering it.

The most expensive model is not automatically the safest. The correct choice is the least complex platform that still meets the required isolation, observability, and recovery objectives.

Build an exit path for every client

Client portability is part of good infrastructure design. Maintain an inventory of domains, applications, databases, mailboxes, certificates, third-party integrations, licenses, and backup locations. Record who owns each asset and which credentials are needed for transfer.

A clean handover package can include:

a current filesystem archive;
a consistent database export;
DNS records and TTL values;
runtime and PHP extension requirements;
scheduled tasks;
external service dependencies;
license ownership;
a restore or migration runbook;
confirmation that agency-only credentials were removed.

If a site cannot be exported and restored without tribal knowledge, the environment is not yet operationally mature.

A practical migration sequence

An agency moving away from one large shared account should avoid a single portfolio-wide cutover. Migrate in controlled batches.

Inventory every site, domain, database, mailbox, job, and integration.
Rank clients by business impact, technical complexity, and current risk.
Establish separate destination accounts and unique credentials.
Test backup restoration before changing DNS.
Lower DNS TTL only when the migration schedule justifies it.
Synchronize files and databases using a documented cutover method.
Validate dynamic workflows, not only cached pages.
Monitor errors, latency, email, and background jobs after cutover.
Keep the old environment read-only for an agreed rollback window.
Revoke obsolete credentials and securely retire residual data.

Start with a representative low-risk client, improve the runbook, and then move more critical sites. The goal is repeatability, not speed on the first migration.

Measure the result

The new architecture is successful when incidents become smaller, diagnosis becomes faster, and recovery becomes predictable.

Useful portfolio-level measures include:

percentage of clients in separate accounts;
percentage with tested restores in the last quarter;
median and worst-case restore time;
number of shared credentials;
sites repeatedly exceeding resource budgets;
patch and update lead time;
failed backup or cron jobs;
incidents that crossed a client boundary.

These metrics turn “better hosting” into an operating system the agency can review and improve.

Isolation is a business feature

Separating client sites is not only a security improvement. It clarifies ownership, limits incident scope, makes billing and capacity visible, simplifies access changes, and gives every customer a credible recovery story.

Begin with the failure domain. Give each client an identity and resource boundary. Test restoration instead of trusting backup status. Keep staging, DNS, email, and credentials out of the production blast radius. Then select individual hosting, reseller hosting, or a managed virtual server according to the team's real operating capability.

That approach scales an agency more safely than counting how many domains still fit inside one account.

Benchmarking a Ryzen VDS Without Fooling Yourself: CPU Scheduling, Storage Latency, and Reproducible Tests

EniyiSunucum — Sat, 19 Sep 2026 16:33:17 +0000

A virtual server benchmark is easy to run and surprisingly hard to interpret. A single attractive score can be caused by a short turbo window, a warm cache, an idle host, or a storage queue that does not resemble the application. A disappointing score can be equally misleading: perhaps another guest briefly competed for CPU time, package updates were running, or the test measured throughput when the workload actually depends on latency.

This article describes a small, repeatable method for evaluating a Linux VDS on KVM. It is not a ranking system and it does not produce one universal “performance number.” The goal is to separate three questions:

Is the guest receiving predictable CPU time?
How does one guest vCPU behave, and how well do several vCPUs scale?
What latency does storage deliver at both low and moderate queue depth?

The method deliberately favors evidence that can be retained and reviewed: metadata, warm-up rules, repeated runs, latency percentiles, and raw output.

Start with a test contract

Before installing a benchmark, write down what decision the result must support. A web worker, a compilation runner, and a nightly database report stress different parts of a system. A Ryzen VDS configuration table can serve as one example of the source profile: record the listed vCPU count, memory, and storage allocation as test inputs, not as evidence of the outcome. Then add the workload’s runtime, concurrency, and I/O pattern before choosing any synthetic test.

Record the environment at the beginning of every test session:

date -u
uname -a
lscpu
nproc
free -h
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
findmnt -no SOURCE,FSTYPE,OPTIONS /

Also record the VDS plan, vCPU count, memory, guest kernel, filesystem, virtualization-visible CPU model, benchmark tool versions, test-file path and size, and the UTC start and end times. Do not infer the physical host topology from lscpu inside the guest. KVM exposes a virtual topology, and a provider may map or migrate vCPUs without making the underlying layout observable.

Choose the measurement window in advance. Avoid backups, package upgrades, log rotation, and application deployments unless those activities are intentionally part of the test. For a production guest, set explicit load and latency stop conditions. A benchmark that harms the workload it is meant to evaluate has failed operationally even if its data is technically valid.

Observe scheduling before measuring CPU

In a KVM guest, a runnable vCPU still needs a host CPU thread on which to run. Linux reports time when the guest wanted to run but the hypervisor scheduled something else as %steal. Capture a quiet baseline, then capture the same counters while the CPU test runs:

mkdir -p results
mpstat -P ALL 1 60 | tee results/mpstat-baseline.txt
vmstat 1 60 | tee results/vmstat-baseline.txt

mpstat -P ALL matters because an aggregate can hide one unstable vCPU. Save per-vCPU %usr, %sys, %iowait, and %steal. vmstat adds runnable tasks (r), blocked tasks (b), context switches, and a second view of CPU state.

Steal time is evidence, not a verdict. One non-zero sample may be harmless, and low steal does not prove that the CPU is dedicated. Look for coincidence: did throughput fall in the same seconds that steal rose? Does the pattern repeat in several runs or at different times of day? A sustained or recurrent correlation is more useful than a screenshot of one peak.

Do not interpret %iowait as disk latency. It is CPU accounting time during which a CPU was idle while I/O was outstanding. A system can have slow I/O and little iowait when other runnable work keeps the CPU busy. Storage latency must be measured from the I/O request and observed at the block layer.

Separate single-vCPU speed from scaling

A multi-threaded score mixes at least two properties: per-vCPU execution speed and the scheduler’s ability to run several vCPUs concurrently. Measure them separately. sysbench is convenient, but its version and parameters must be retained because scores from different builds or prime limits are not directly comparable.

First warm the code path, then run one worker pinned to one guest vCPU:

taskset -c 0 sysbench cpu --threads=1 --time=20 \
  --cpu-max-prime=20000 run >/dev/null

taskset -c 0 sysbench cpu --threads=1 --time=60 \
  --cpu-max-prime=20000 run | tee results/cpu-1t-run01.txt

taskset prevents the process from moving among guest vCPUs, which removes one source of variation. It does not pin the workload to a physical Ryzen core on the host; only the hypervisor operator can make that guarantee. Repeat the timed run at least five times. Rotate the selected guest CPU in a separate experiment if you want to detect an unusually noisy vCPU, but do not silently mix those results into the primary series.

Then test the intended concurrency. For a four-vCPU guest:

sysbench cpu --threads=4 --time=20 \
  --cpu-max-prime=20000 run >/dev/null

sysbench cpu --threads=4 --time=60 \
  --cpu-max-prime=20000 run | tee results/cpu-4t-run01.txt

Run mpstat -P ALL 1 in another shell during both tests. Report events per second and total events, plus the median, minimum, and maximum across repetitions. Scaling efficiency can be expressed as:

efficiency = multi-thread throughput / (single-thread throughput × worker count)

Efficiency below 100% is normal because of scheduling, shared caches, memory bandwidth, and benchmark overhead. The useful signal is reproducibility. Stable single-thread results with volatile multi-thread results and matching steal spikes suggest scheduling contention. Stable results at both thread counts make that explanation less likely.

Do not compare a 30-second result on one server with a 10-minute result on another. Boost behavior, thermal state, host power policy, and contention can change over time. Keep duration, worker count, affinity policy, tool version, and warm-up identical.

Measure storage without turning a read test into a write test

Use fio only against a dedicated test file that already exists and was provisioned during a maintenance window. Never point a casual benchmark at a database file, a mounted block device, or an unknown path. Verify the target before every run:

realpath /srv/benchmark/fio-test.bin
stat /srv/benchmark/fio-test.bin
findmnt -T /srv/benchmark/fio-test.bin
fio --version

The following low-queue-depth test is read-only. --readonly is a safety check that rejects write or trim workloads; it is worth keeping even when --rw=randread is already specified.

fio --name=randread-4k-q1 \
  --filename=/srv/benchmark/fio-test.bin \
  --readonly --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 \
  --iodepth=1 --numjobs=1 \
  --time_based=1 --runtime=90 --ramp_time=20 \
  --randrepeat=1 --randseed=20260919 \
  --lat_percentiles=1 --percentile_list=50:95:99:99.9 \
  --group_reporting --output-format=json \
  --output=results/fio-4k-q1-run01.json

--direct=1 reduces page cache effects, but it does not bypass every cache in the storage path. --ramp_time=20 gives the system a warm-up interval before statistics are collected. A fixed random seed makes the access sequence repeatable; that improves controlled comparison but can favor an upstream cache on later runs. State explicitly whether the objective is cold behavior, warmed steady state, or both. Do not claim “raw disk” performance from a virtual guest.

Low queue depth is useful for latency-sensitive operations. Add a separate test at a queue depth and job count that resemble the application—for example QD32 for a deliberately concurrent workload—but do not replace QD1 with it. High concurrency can produce impressive IOPS while individual requests wait longer.

During each fio run, observe the guest block layer:

iostat -xz 1 120 | tee results/iostat-fio-q1-run01.txt

In extended iostat output, r_await is the average time for read requests, including queue and service time. aqu-sz shows the average queue length. %util can be informative, but in a virtual or parallel storage stack it is not a universal saturation gauge. Interpret these fields together with fio latency and IOPS, not in isolation.

Prefer percentiles to averages

An average conceals the tail. If 99 reads finish in 0.5 ms and one takes 100 ms, the mean does not describe the pause that a request-sensitive application experiences. Retain at least p50, p95, p99, and preferably p99.9 latency from fio. Keep the units visible: depending on the output and version, latency values may be represented in nanoseconds or microseconds.

Percentiles within a run answer “how were individual requests distributed?” Repetitions answer a different question: “how stable is the environment across runs?” Do not compute a persuasive-looking p99 from only five aggregate scores. For each scenario, report the median result across at least five runs, along with its minimum and maximum. Preserve the within-run p95 and p99 from every raw JSON file.

Run the series in more than one time window if neighbor activity is part of the risk being evaluated. Use the same sequence, or alternate scenario order to prevent every QD32 test from always inheriting the warmest cache. Note every deviation rather than deleting an inconvenient run. Exclude a run only by a rule defined before testing, such as an OS update process appearing in the log.

Keep a reproducible evidence bundle

A useful result directory is understandable months later:

results/
├── metadata.txt
├── mpstat-baseline.txt
├── cpu-1t-run01.txt
├── cpu-4t-run01.txt
├── fio-4k-q1-run01.json
├── iostat-fio-q1-run01.txt
└── notes.md

Store exact commands in notes.md. Hash the raw files after the session so later processing cannot silently change the evidence:

sha256sum results/* > results/SHA256SUMS

When comparing two VDS configurations, change one factor at a time and use the same guest image, kernel, filesystem, test-file size, duration, and tool versions. Raw data should accompany summary tables. A chart without the command and source output is an illustration, not a reproducible benchmark.

Turn observations into decisions

Avoid universal pass/fail numbers. Define thresholds from the application’s service objective, then use patterns such as these:

Observation	Plausible interpretation	Next check
Single-thread throughput is stable; multi-thread throughput varies with `%steal`	Host scheduling contention is affecting parallel work	Repeat in another time window and correlate per-vCPU steal with each run
CPU results are stable; QD1 p99 read latency is high	Latency-sensitive storage work may be at risk	Compare with an application trace and inspect `r_await` and queue depth
QD1 latency is acceptable; QD32 IOPS is high but p99 grows sharply	Storage benefits from concurrency at a tail-latency cost	Cap application concurrency and test the intended queue depth
`fio` latency and `iostat` `r_await` rise together	Delay is visible through the guest block path	Check queue growth, other guest I/O, and time-of-day repetition
`iostat` is busy but the benchmark remains stable	Another workload may share the device without yet harming the test	Identify the process and repeat in a controlled window
Results drift after warm-up	Boost, caching, throttling, or background activity may dominate short tests	Extend runtime and retain a time series instead of one total

The final decision should name the workload and its tolerance: for example, “p99 4 KiB read latency must remain below the application’s measured limit while four CPU workers meet the batch deadline.” That is defensible. “This VDS scored X” is not.

A benchmark as a controlled argument

A credible VDS benchmark does not need dozens of tools. It needs a declared question, a safe target, observable scheduling, separate single- and multi-vCPU tests, storage tests at realistic queue depths, warm-up, repetitions, and raw evidence. On KVM, %steal helps explain missing CPU time; it does not explain everything. For storage, await and average latency provide context, while p95 and p99 reveal the pauses users are more likely to notice.

The most valuable outcome is not the highest number. It is a result that another engineer can reproduce, challenge, and connect to a real workload.

Türkçe paket karşılaştırma kaynakları

Bu rehber EniyiSunucum tarafından yayımlanmıştır. Yukarıdaki ölçüm yöntemini uygularken seçtiğiniz paketin vCPU, RAM ve depolama sınırlarını test notlarınıza ekleyin. Sonuçları farklı paketlerle karşılaştırırken test süresini, eşzamanlı iş sayısını ve veri boyutunu sabit tutun.

Türkçe ürün tablolarımızda sanal sunucu kaynaklarını vds satın al ve vps satın al sayfalarından inceleyebilirsiniz. AMD Ryzen işlemcili seçenekler için ryzen vds kirala sayfamızdaki paket kaynaklarını karşılaştırabilirsiniz. Bu bağlantılar şirketimizin kendi ürün sayfalarıdır; yayınlanan kaynak miktarları, uygulamanız için ölçülmüş performans sonucu anlamına gelmez.

Disclosure

This article was drafted with AI assistance. Commands, tool behavior, and safety assumptions should be checked against the versions installed on the target system and validated in a non-production environment before use.

Your XenForo Forum Is Slow: A Measurement-First PHP-FPM and MySQL Runbook

EniyiSunucum — Fri, 18 Sep 2026 12:45:53 +0000

A slow forum is rarely fixed by changing one PHP setting or buying a larger server blindly. The useful question is not Is the server slow? but Which queue grows when users feel the slowdown?

This runbook separates four common causes of XenForo latency: CPU contention, PHP-FPM saturation, MySQL work, and storage delay. Every command below is read-only unless a step explicitly says otherwise. Capture a normal window and an incident window with the same commands; isolated screenshots are weak evidence.

1. Define the symptom before touching the stack

Record one UTC interval when the forum is healthy and one when it is slow. For each interval, keep:

the affected URL class: thread view, search, login, posting, attachment upload, or admin task
application response time, preferably p50, p95, and p99 rather than only an average
HTTP status codes and upstream response time from the web-server access log
concurrent requests and logged-in user count
scheduled jobs, backups, imports, search indexing, and add-on maintenance running at that time.

Use one incident directory so timestamps line up:

incident="/var/tmp/xf-$(date -u +%Y%m%dT%H%M%SZ)"
install -d -m 700 "$incident"
date -u --iso-8601=seconds | tee "$incident/start.txt"
uname -a > "$incident/kernel.txt"
uptime > "$incident/uptime.txt"
free -m > "$incident/memory.txt"
df -hT > "$incident/filesystems.txt"

Do not publish raw logs before removing IP addresses, usernames, query strings, cookies, tokens, and private paths.

2. Decide whether the wait begins at CPU or storage

Collect CPU, run-queue, pressure-stall, process, and block-device data during the same 60-second window:

LC_ALL=C mpstat -P ALL 1 60 > "$incident/mpstat.txt" &
LC_ALL=C vmstat -w -t 1 60 > "$incident/vmstat.txt" &
LC_ALL=C pidstat -u -d -w -p ALL 1 60 > "$incident/pidstat.txt" &
LC_ALL=C iostat -xz -t 1 60 > "$incident/iostat.txt" &
wait

Interpret combinations, not single columns:

A sustained run queue above the available vCPU count, high CPU pressure, and low idle time points to guest-side CPU saturation.
Rising steal time that coincides with application latency can indicate hypervisor scheduling delay. A zero value does not prove that the host is perfect, but a correlated rise is useful evidence.
Rising read or write latency, queue depth, and I/O pressure points toward the storage path. Do not treat device utilization alone as a universal saturation signal on virtual disks or modern SSDs.
High iowait is a clue, not a diagnosis. Correlate it with device latency, pressure, and the processes issuing I/O.

If /proc/pressure/cpu and /proc/pressure/io exist, sample them once per second. PSI tells you how much time runnable work is stalled, which is often closer to the user-visible problem than a five-minute load average.

3. Check PHP-FPM as a queue, not as a memory formula

A busy forum can be slow while the host still has free CPU because requests are waiting for PHP workers. Enable the PHP-FPM status endpoint only on a private management path protected by an allowlist or local socket. Never expose it publicly.

During the incident, compare:

active processes versus the configured maximum
max-active-processes and max-children-reached counters
listen-queue depth and its historical maximum
slow-request records from the FPM slow log
resident memory per worker under realistic traffic.

If max children reached increases while the CPU is not saturated, requests are queuing at FPM. Raising the worker limit may help only when memory and database capacity exist. Estimate from observed RSS, leave room for MySQL, the kernel page cache, the web server, and traffic spikes, then change one variable in a maintenance window.

If workers are busy for a long time, adding more can amplify the real bottleneck. Use the slow log to find whether workers wait on database queries, remote APIs, filesystem operations, or add-on code.

4. Separate MySQL concurrency from slow individual queries

Start with current state:

SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Threads_connected', 'Threads_running',
  'Created_tmp_disk_tables', 'Created_tmp_tables',
  'Innodb_buffer_pool_reads', 'Innodb_buffer_pool_read_requests',
  'Innodb_row_lock_time', 'Innodb_row_lock_waits'
);
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS;

Capture these at the same time as the Linux metrics. A large connection count is not automatically bad; Threads_running, lock waits, and query latency are more useful. Likewise, a buffer-pool miss counter is cumulative, so compare deltas over a fixed interval.

If Performance Schema is enabled, identify statement digests with high total latency, high rows examined, or repeated executions. Inspect representative queries with EXPLAIN on a staging copy or during a controlled diagnostic window. Do not add indexes from intuition alone: an index can improve reads while increasing write cost and storage.

A temporary slow-query-log window can be valuable, but enabling it changes server state and may write sensitive query data. Plan it, protect the log, set a short observation period, and disable it after collection.

5. Test XenForo-specific suspects one at a time

Infrastructure graphs cannot identify every application cause. Common forum-side suspects include:

an add-on executing work on every page view
search or indexing tasks overlapping peak traffic
attachment or image processing bursts
scheduled jobs, email queues, imports, and sitemap generation
external API calls inside request handling
session, permission, or template work made expensive by an add-on
a large thread or search path that produces unusually heavy queries.

Reproduce the slow URL with the same account permissions in staging. Disable one suspect add-on at a time there, keep caches and dataset size comparable, and record the before-and-after request trace. Clearing every cache, restarting every service, and changing multiple limits simultaneously destroys the evidence you need.

6. Use a decision table

Evidence during the same interval	First hypothesis	Next check
FPM queue grows; CPU and MySQL are calm	Worker capacity or blocked PHP calls	FPM slow log and per-worker RSS
`Threads_running` and lock waits rise	Database contention	statement digests, InnoDB status, transaction scope
CPU PSI and run queue rise; steal stays low	Guest CPU saturation	hot processes, add-ons, request mix
Steal rises with latency; guest CPU is not full	Hypervisor scheduling pressure	repeatable timestamps for the provider
I/O PSI and device latency rise together	Storage-path contention	per-process I/O, backup/index tasks, provider evidence
Only one route is slow	Application/query path	request trace and query digest

The table is a prioritization tool, not proof by itself. Repeat the observation and look for the same correlation before migrating or resizing.

7. Scale only after the bottleneck has a name

More vCPU helps a CPU-bound workload only when useful work can run in parallel. Faster single-core performance can matter for serial PHP execution, but it will not fix a locked database transaction. More RAM can reduce disk reads when the working set does not fit, but it will not repair an unindexed query. NVMe can reduce storage latency, but it will not clear an FPM listen queue caused by a remote API.

When comparing shared hosting, VPS, or VDS, carry your evidence into the decision: sustained CPU demand, measured memory working set, database size, p95 storage latency, peak concurrent PHP workers, backup window, and growth margin. The product label is less important than verified resource boundaries and an upgrade path.

A practical handoff bundle

A useful incident bundle contains UTC start and end times, the affected URLs, application percentiles, web-server upstream timings, FPM status and slow traces, MySQL snapshots, Linux CPU/I/O evidence, exact package versions, and a short list of changes made. Add checksums after collection so later edits are visible.

That bundle turns “the forum feels slow” into a claim another engineer or provider can test.

Disclosure: This article was prepared by the EniyiSunucum infrastructure team, which provides server and hosting services. Readers evaluating managed environments can compare XenForo hosting options, but the diagnostic method above is provider-neutral and contains no unpublished benchmark claims. AI assistance was used for structure and language editing; commands, interpretations, and links were reviewed before publication.

CPU Looks Fine but the VDS Is Slow: A Linux Incident Runbook

EniyiSunucum — Thu, 17 Sep 2026 00:17:29 +0000

A user reports that an application is slow or intermittently unreachable. The monitoring dashboard shows 20% CPU, memory still available, and no obvious outage. It is tempting to answer, “the server looks healthy.”

That answer is usually premature.

A single CPU graph cannot tell you whether a Linux guest is waiting on storage, reclaiming memory, losing packets, stalling inside a cgroup, contending for hypervisor time, or following a degraded network path. The useful question is not “is CPU high?” but where did the request spend its time?

This runbook provides a repeatable way to answer that question on a Linux virtual server. It starts with low-risk evidence, separates guest-level faults from upstream faults, and produces a compact incident package you can hand to an application team or infrastructure provider.

Safety note: The first stages below are read-only. Run load generators such as fio or iperf3 only during an approved window, against endpoints you control, and with explicit rate limits. Never benchmark a production filesystem or a third-party host without permission.

1. Freeze the incident boundary

Before collecting metrics, write down four facts:

The exact start and end time in UTC.
The affected hostname, IP, port, and protocol.
Whether all clients were affected or only one location/ISP.
One concrete symptom: timeout, connection reset, slow TTFB, packet loss, or high application latency.

Capture a small identity bundle:

date -u -Is
hostnamectl
uname -a
uptime
who -b
journalctl --list-boots | head

This prevents a common failure: comparing a user report from 14:05 with metrics from 14:40, after the system has already recovered.

If the problem is HTTP, record timings from both the server and an external client:

time curl -sS -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://example.com/

Repeat the same request against localhost or the private service address when possible. Fast locally but slow externally points away from the application process and toward the proxy, firewall, network, or client path.

2. Read CPU as a scheduler, not a percentage

Start with a short time series rather than a single snapshot:

vmstat 1 10
mpstat -P ALL 1 10
pidstat -u -w 1 10

These commands are provided by procps and sysstat on most distributions.

Pay attention to:

r in vmstat: runnable tasks waiting for CPU.
b: tasks blocked, often on I/O.
wa: time waiting for I/O.
st: steal time, when the virtual CPU was ready but the hypervisor scheduled something else.
Context switches and migrations in pidstat.

Low aggregate CPU does not rule out saturation. One single-threaded worker can max one vCPU while the average across eight vCPUs remains near 12.5%. Per-CPU output from mpstat exposes that pattern.

Sustained steal time that correlates with latency is strong evidence of host-side contention, but one sample is not proof. Capture several intervals and correlate them with application timing.

Linux Pressure Stall Information adds another useful view:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

The “some” and “full” lines describe how much time tasks were delayed because a resource was unavailable. PSI is often more informative than utilization because it measures waiting experienced by workloads.

3. Distinguish available memory from memory pressure

Linux deliberately uses free RAM for cache, so the “free” column alone is not an alarm. Look for reclaim, swap activity, and allocation failures:

free -h
vmstat 1 10
cat /proc/pressure/memory
ps -eo pid,ppid,comm,%mem,rss,vsz --sort=-rss | head -20
journalctl -k --since '-30 min' | grep -Ei 'oom|out of memory|memory cgroup'

Interpret the evidence together:

Continuous si/so in vmstat indicates active swapping.
Rising memory PSI means tasks are stalling during reclaim.
OOM or memory-cgroup messages explain sudden process restarts.
A large page cache with low swap activity is usually normal.

Inside containers, host memory may look comfortable while a service is hitting its cgroup limit. On cgroup v2 systems, inspect the relevant scope under /sys/fs/cgroup and compare memory.current with memory.max. Do not assume the VM total is the service limit.

4. Check storage latency, not only disk usage

A filesystem can have plenty of free space and still respond slowly. First rule out capacity and inode exhaustion:

df -hT
df -i
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

Then sample the block layer:

iostat -xz 1 10
pidstat -d 1 10
cat /proc/pressure/io
journalctl -k --since '-30 min' | grep -Ei 'I/O error|timeout|reset|nvme|blk_update'

Useful indicators include:

await: average time for an I/O request to complete.
Queue size: sustained queues suggest the device cannot keep up.
I/O PSI: application-visible time lost waiting on storage.
Per-process reads and writes from pidstat.

Treat %util carefully on modern virtual and parallel storage. A high value can be meaningful, but a low value does not guarantee low latency. The combination of await, queueing, PSI, and application timing is stronger than any one number.

Avoid immediately running fio. A benchmark can turn a partial incident into a full outage and can contaminate the very evidence you are trying to preserve. If a controlled test is necessary, use a disposable file, direct I/O where appropriate, a fixed size, a runtime limit, and an agreed bandwidth or IOPS cap.

5. Inspect sockets and the network stack

Begin at the guest boundary:

ss -s
ss -lntup
ss -tin
ip -s link
nstat -az
sar -n DEV,TCP,ETCP 1 10

Look for:

Retransmissions increasing during the incident.
Receive or transmit drops on the interface.
A growing listen or SYN backlog.
Many sockets stuck in SYN-SENT, SYN-RECV, or CLOSE-WAIT.
TCP RTT and retransmission fields in ss -tin.

If the interface counters are clean but the application times out, inspect each layer of the request path: resolver, firewall, reverse proxy, application listener, and upstream dependency.

For DNS, compare authoritative and recursive answers:

dig example.com A +noall +answer +stats
dig @1.1.1.1 example.com A +noall +answer +stats
resolvectl query example.com

A slow resolver can make an otherwise healthy service feel randomly slow, especially when caches expire.

6. Test the path without over-reading ICMP

From a client that actually experienced the problem, collect a bounded path sample:

mtr -rwzc 50 server.example.com
tracepath server.example.com

Run the reverse direction when you control both endpoints. Internet paths are often asymmetric.

Do not diagnose packet loss from one intermediate hop alone. Routers may rate-limit or deprioritize ICMP while continuing to forward application traffic normally. Loss becomes meaningful when it begins at a hop and persists through later hops, especially to the destination, and when it correlates with TCP or application symptoms.

Use iperf3 only between systems you control. Start the server on one endpoint, choose a modest bandwidth cap for UDP tests, and stop if the link or production workload degrades. Throughput is not a substitute for application timing; it is one controlled data point.

7. Add external routing evidence

When the guest looks healthy but multiple remote networks fail, check the route from outside your infrastructure:

Is the prefix visible from several public route collectors?
Did the origin ASN change?
Is the announcement covered by a valid RPKI Route Origin Authorization?
Did the AS path change near the incident time?
Is the problem limited to one region or upstream?

A route visible from one collector is not proof of global reachability. Compare more than one vantage point and record timestamps. This is especially important for regional hosting, where an upstream or peering issue may affect one country while local monitoring stays green.

8. Decide which boundary owns the next action

Use the evidence to route the incident:

Evidence	Most likely next owner
One process or one vCPU saturated	Application/service team
Swap, memory PSI, or cgroup limit	Guest configuration/application team
High await, queueing, and I/O PSI	Storage or infrastructure team
Sustained steal time with normal guest load	Virtualization provider
Interface drops or retransmits from the guest	Guest networking or provider edge
Clean guest, path degradation across several clients	Network/upstream provider
Local service fast, public hostname slow	DNS, proxy, firewall, or network path

This table is not a verdict. It tells you where the next discriminating test belongs.

9. Build an evidence package a provider can act on

A useful escalation is short and reproducible. Include:

VM identifier and affected public IP.
UTC incident window.
Source locations or ISPs affected.
Exact destination IP, port, and protocol.
Ten to sixty seconds of vmstat, mpstat, iostat, PSI, and interface counters.
Application timing from inside and outside.
MTR from both directions when available.
Public routing observations and timestamps.
A clear request, such as “please check host scheduling for this VM between 14:02 and 14:09 UTC.”

Avoid screenshots without axes, “the network is slow,” or a five-megabyte log dump with no timeline. The goal is to let another engineer test a specific hypothesis.

10. Keep the runbook lightweight

The best incident kit is the one already installed and practiced. A small baseline of sysstat, curl, dig, mtr, and journal access covers a large share of Linux performance incidents. Add persistent monitoring for PSI, steal time, disk latency, retransmissions, and application percentiles so the next investigation begins with history instead of guesswork.

A VDS plan should make the CPU allocation, memory limit, storage type, network policy, and support boundary explicit. Those details determine which signals you can observe and which evidence your provider must supply.

Final principle

When CPU looks fine, do not jump straight to a benchmark or a provider ticket. Follow the request across boundaries:

application → scheduler → memory → storage → socket → guest interface → network path → routing

At each boundary, collect one time-stamped signal that can falsify a hypothesis. That turns “the server is slow” into an incident another engineer can reproduce and resolve.

Disclosure: I work on Linux-based virtual server infrastructure and AS215068 at EniyiSunucum. This runbook is vendor-neutral and the commands apply to standard Linux environments.