"The server feels slow" can mean three different things: the network is busy, something on the server is using the bandwidth, or the test itself is wrong. These seven steps tell them apart. Commands are for Linux; package names are for systems that use apt.
1. Look at the dashboard graphs
Open the server in the dashboard and go to the Metrics tab. The network chart shows incoming and outgoing traffic per second for the last hour, day or week. The data comes from the virtualization layer, so it's there even when the OS inside the server is stuck.
Two things it doesn't show: totals in gigabytes, and which program made the traffic. That's what the next steps are for.
The same data is available over the API, including the last month:
curl -s "https://api.eqvps.com/api/v1/eqvps/services/SERVICE_ID/metrics?timeframe=month" \
-H "Authorization: Bearer $EQVPS_API_KEY"
2. Find your network interface
Most commands below need the interface name:
ip -br addr
The interface with your public (or, on NAT servers, private) address is the one you want, often eth0 or ens18. Replace eth0 below if yours differs.
3. Count traffic per day and month with vnStat
apt install -y vnstat
vnstat -l -i eth0 # live rate, Ctrl+C to stop
vnstat -d # per day
vnstat -m # per month
vnStat reads the kernel's interface counters, survives reboots and costs almost nothing to run. It starts counting when you install it, so install it before you need the numbers.
4. See which process uses the bandwidth
apt install -y nethogs
nethogs eth0
nethogs lists processes with their current send and receive rates. If you see a process you don't recognise pushing traffic, look at it closely: an unexpected heavy uploader can mean a compromised server.
To see the connections themselves:
ss -tunap | head -30
5. Run a speed test that means something
The reliable way is iperf3 between two machines you control. On the other machine, start the server:
iperf3 -s
On your server, test both directions with 4 streams for 30 seconds:
iperf3 -c OTHER_HOST -P 4 -t 30 # upload from this server
iperf3 -c OTHER_HOST -P 4 -t 30 -R # download to this server
A NAT server accepts inbound connections only on its SSH port, so run iperf3 -s on the other machine and keep the NAT server as the client, as above.
No second machine? Download a large file from a fast mirror near you and read the average:
curl -o /dev/null -w "%{speed_download}\n" https://mirror.example.net/1GB.bin
The result is in bytes per second. Multiply by 8 for bits per second: 110000000 is about 880 Mbit/s.
6. Check latency and packet loss
Low throughput across long distances is often a latency or loss problem, not a bandwidth one:
apt install -y mtr-tiny
mtr -rwc 100 example.com
Look at the Loss% column on the last line. Loss that appears at one hop in the middle and disappears further on is usually that router deprioritising ping replies, not real loss.
7. Compare with what to expect
| Plan | Port | Typical result with 4 streams, quiet line |
|---|---|---|
| Linux VPS | 1 Gbit/s | about 900–940 Mbit/s each way |
| Windows VPS | 150 Mbit/s | about 140 Mbit/s |
When several servers on the same physical machine are busy at once, the uplink is split evenly between them, so a lower number at a busy moment is expected. There's no traffic quota on any plan. How the sharing works is explained in Traffic and network speed.
On a Windows server, Task Manager → Performance → Ethernet shows the live rate, and Resource Monitor → Network shows traffic per process.
If the numbers are really low
Run step 5 against two different test servers, write down the time, and open a ticket with the commands and their output. With that we can check the uplink at that exact moment.
Related
- Traffic and network speed: port speeds, fair sharing, outbound mail ports.
- Network & ports: NAT forwarding and open ports.
- Free up disk space, if vnStat or logs fill the disk.
Comments
No comments yet. Be the first.