> ## Documentation Index > Fetch the complete documentation index at: https://docs.advinservers.com/llms.txt > Use this file to discover all available pages before exploring further. # Hardware Issues > How to diagnose and report CPU, disk, and memory problems on your server. ## Overview Hardware issues can occasionally occur where something is not working correctly and our monitoring systems have not picked up on it. This is usually unsatisfactory CPU performance, slow disk performance, or a fault with the server hardware itself. This page explains how to diagnose each of these and what information to collect before opening a ticket. As always, please open a ticket if you run into any problems, even if you are unsure of the cause. We greatly appreciate these reports, as they allow us to find underlying issues that our monitoring may have missed. If you are troubleshooting slow downloads, high latency, or packet loss, see [Network Problems](/troubleshooting/network) instead. ## Before You Start Before assuming a hardware fault, rule out the most common causes, which are almost always inside the server itself: * **Runaway processes.** Run `top` or `htop` and check whether a single process is consuming all of the CPU or memory. * **Memory exhaustion and swapping.** Run `free -h`. If your server is out of memory and swapping heavily, everything will feel slow, including the disk. * **A full disk.** Run `df -h` and `df -i`. A disk at 100 percent capacity, or one that is out of inodes, causes failures that look like hardware faults. * **Recent changes.** Consider whether the problem started after a package update, a kernel upgrade, a configuration change, or a new workload being deployed. * **A reboot.** If the server has been running for a long time or is in an unclear state, a clean reboot from the [Ascienth console](/guides/controlpanel) is worth trying first. It is also worth checking whether the problem is constant or happens only at certain times of day. That distinction is very useful to us when investigating. ## CPU Performance ### Checking CPU Steal If you are experiencing unsatisfactory CPU performance on a virtual server, run the `top` command and check the value labelled `st` on the CPU line. This indicates CPU steal, which is the percentage of CPU time your VPS is waiting on from the hypervisor. ``` %Cpu(s): 4.2 us, 1.1 sy, 0.0 ni, 94.5 id, 0.1 wa, 0.0 hi, 0.1 si, 0.0 st ``` We generally aim to keep CPU steal at 0 percent across our hypervisors. However, in some cases where CPU contention is higher, you may see values between 5 and 10 percent. This is not unusual in shared environments where multiple virtual servers are competing for CPU resources. Even if the hypervisor still has CPU headroom, some steal can occur if the host is above 50 percent usage and starting to rely on hyperthreading, or due to other low-level factors. **If your CPU steal value regularly exceeds 10 percent, please open a support ticket.** ### Monitoring Steal Over Time CPU steal often fluctuates, so a single `top` reading is rarely enough to demonstrate a problem. Tools such as HetrixTools or Netdata can monitor CPU steal continuously without you having to watch `top`. These tools generate graphs that are very helpful for our team when diagnosing patterns or identifying specific times when performance degrades. If you cannot install a monitoring agent, you can still capture a short sample from the command line: ``` vmstat 1 60 ``` This prints one line per second for 60 seconds. The `st` column at the far right is CPU steal. Send us the full output along with the time and timezone it was captured. ### If There Is No Steal If you are not seeing any CPU steal but performance is still poor, please reach out and we can investigate further. A few things worth knowing first: * Benchmarks such as Geekbench may report lower scores when the VPS is using hyperthreaded vCPU cores. * The clock speed reported inside your VM is frequently inaccurate. See [Hardware Information](/information/hardware) for details on the processors we use and the clock speeds they actually run at. * In rare cases, abnormal CPU steal is caused by a hardware fault rather than contention. We have seen situations where faulty memory led to spikes in CPU steal despite otherwise normal conditions. ### Dedicated Servers CPU steal does not exist on dedicated or bare metal machines, since there is no hypervisor scheduling your cores. If you are seeing performance issues on dedicated hardware, install `lm-sensors` and check the CPU temperatures as a first step: ``` sudo apt install lm-sensors sudo sensors-detect --auto sensors ``` Sustained temperatures at or near the processor's thermal limit will cause it to throttle and lose performance. If you see this, please open a ticket so that we can inspect the cooling on the machine. ## Disk Performance ### Running a Benchmark We use enterprise Gen3 or Gen4 NVMe SSDs across almost all of our VPS hypervisors, so disk performance issues are extraordinarily rare. To measure your disk, we recommend running the following and checking the `fio` results it outputs: ``` curl -sL yabs.sh | bash -s -- -i -g -n ``` Note that `yabs.sh` is a third-party tool, so use it at your own risk. ### Interpreting the Results As long as the 1m result is above 1 GB/s and the 4k results are above 100 MB/s, your disk performance is within the expected range. Our virtual servers typically exceed these figures by a wide margin, as in the sample output below: ``` fio Disk Speed Tests (Mixed R/W 50/50): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 219.67 MB/s (54.9k) | 1.64 GB/s (25.7k) Write | 220.25 MB/s (55.0k) | 1.65 GB/s (25.8k) Total | 439.93 MB/s (109.9k) | 3.30 GB/s (51.5k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 4.30 GB/s (8.4k) | 4.91 GB/s (4.7k) Write | 4.53 GB/s (8.8k) | 5.24 GB/s (5.1k) Total | 8.84 GB/s (17.2k) | 10.15 GB/s (9.9k) ``` Keep two things in mind when comparing your numbers: * Disk throughput is shared between the virtual servers on a hypervisor, so results will vary somewhat between runs. * Linux caches disk contents in memory, which can inflate 4k and 1m results well above what the underlying storage can sustain. **If you are consistently seeing under 1 GB/s on 1m or under 100 MB/s on 4k, please open a ticket so that we can investigate.** ### High I/O Wait If throughput looks acceptable but the server still feels slow, check the `wa` (I/O wait) value in `top`. A persistently high I/O wait combined with low throughput usually points to a workload issuing a large number of small synchronous writes, such as an unoptimised database. Running `iostat -x 1` from the `sysstat` package will show you which device is busy and how long requests are queuing. ## Memory Issues If processes on your server are being killed unexpectedly, check whether the kernel is running out of memory before suspecting faulty hardware: ``` sudo dmesg -T | grep -i -e "out of memory" -e "killed process" ``` Entries here mean the OOM killer terminated a process because the server ran out of available memory. That is a capacity issue rather than a hardware fault, and is resolved by reducing memory usage, adding swap, or upgrading your plan. On dedicated servers you can also check for correctable and uncorrectable ECC memory errors: ``` sudo dmesg -T | grep -i -e edac -e "hardware error" -e mce ``` Any uncorrectable errors, or a steadily increasing count of correctable errors, should be reported to us immediately so that we can arrange a memory replacement. ECC errors are not visible from inside a virtual server, so if you suspect a memory fault on a VPS, please open a ticket and we will check the host. ## Reporting a Hardware Issue Opening a ticket with the information below lets us start investigating right away instead of asking follow-up questions: * A clear description of the symptom and how you are measuring it. * The date, time, and **timezone** the problem occurred, and whether it is constant or intermittent. * The raw output of any commands you ran, such as `top`, `vmstat 1 60`, or the full `yabs.sh` results. Please paste the text rather than sending a screenshot where possible. * Monitoring graphs covering the period in question, if you have them. * Anything that changed on the server shortly before the problem started. Tickets can be opened from the [client area](https://clients.advinservers.com/contact.php). If we find a fault with the underlying hardware, we will migrate your server to healthy hardware or replace the faulty component, and we will keep you updated throughout. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.