Something happened on Saturday with the host that took their entire network of nodes down across the world, including their own website. When they recovered, things seemed slow and unstable.
I submitted a support ticket. Most hosting support goes to Level 1 techs who just reply that you need to upgrade to a more powerful (and expensive) plan. That was NOT the problem or solution. To avoid this, I tried to explain I could diagnose what needed to be done -- trying not to come across as pushy or rude:
Subject: Storage I/O latency spike since weekend outage – woodcentral.com
Hi,
Since the site/email outage this past weekend, I'm seeing a sustained storage I/O latency problem on my hosting account that started immediately after service was restored. Before the outage, all metrics were healthy; they've stayed degraded since.
Here is output from a health-check script I run against the account:
FS_WRITE Avg=312.78ms P50=0.68ms P95=1351.87ms
FS_SYNC Avg=506.26ms P50=8.06ms P95=2455.42ms
INODE Avg=16.72ms P50=0.09ms P95=99.80ms
DB_CONN Avg=16.31ms P50=1.67ms P95=46.88ms
DB_QUERY Avg=0.16ms P50=0.13ms P95=0.18ms
PHP Avg=1228.37ms P50=356.66ms P95=5024.12ms
The key thing I want to flag: DB_QUERY latency is essentially perfect (P50 0.13ms, P95 0.18ms, almost no spread), which rules out MariaDB query contention, locking, or buffer pool sizing as the cause. The problem shows up specifically in FS_WRITE and FS_SYNC, where the median is fast but the P95 spikes 300–2000x above the median. That pattern — low median, extreme tail — points to intermittent filesystem I/O stalls at the storage layer, not steady-state load on my end. DB_CONN latency is elevated too, which is consistent since establishing a connection touches disk/socket I/O before any query runs.
Given the timing lines up exactly with the outage, could you check whether:
- My account's storage volume was failed over to a different backend during the incident and hasn't moved back
- There's an ongoing RAID rebuild or storage maintenance task on the host affecting I/O
- Other tenants on the same storage array are producing contention (noisy neighbor)
Happy to provide the full script output or run further diagnostics on my end if useful. This is significantly impacting page load times (PHP P95 is now over 5 seconds), so I'd appreciate a look at the storage backend for this account.
Thanks,
Peter
That got escalated to the CEO and owner of the company, who responded:
Hello,
Looks to likely have been a user eating a flood.
The loads a bit of a misread when it comes to servers with Cloudlinux since a single user can cause the load to be 200 just because they don't have enough CPU/etc.
Like, I just suspended the person just now. Even though they were only using ~100% of a single CPU, it made load report back 200. Its annoying
Anyway, things should feel a good bit better.
Francisco
Well, that will work and stop the flood but is overkill. In short, it was due to other accounts on the server consuming too many resources that made things go crazy. This is often referred to as "noisy neighbor" problems. Nothing was wrong with our site. It was those darn neighbors. We may have to move out of the hood to a deluxe host in the cloud.
https://www.youtube.com/watch?v=_-OnRQ4P0VY
Or maybe they could adjust the CloudLinux Lightweight Virtual Environment (LVE) parameters. I'm convinced that is the solution, but I'm not going to push it. 
Your humble Web Guru and Certified Viking
-Peter "Leif Larsson" Martin