All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Servitro - 90% CPU Steal, Kernel Soft Lockups, 36 MB/s Sequential
thiefyzheng
Member
I purchased the Servitro "Virtual-1 AMD EPYC 7443P" from their Offers post for $20 a year.
I received the advertised double RAM and disk upgrade reasonably fast after opening a ticket. I noticed that my VPS had an EPYC 7763 rather than the 7443P listed in the name.
Upon accessing the system over SSH, I noticed a major delay in general responsiveness, such as while running system updates or a git clone.
I ran a disk benchmark and got the following results:
random_rw: (groupid=0, jobs=1): err= 0: pid=16835: Wed May 13 15:05:18 2026
read: IOPS=1663, BW=6655KiB/s (6815kB/s)(390MiB/60001msec)
clat (usec): min=2, max=65327, avg=297.16, stdev=748.71
clat percentiles (usec):
| 99.90th=[10814], 99.99th=[24773]
write: IOPS=1662, BW=6648KiB/s (6808kB/s)(390MiB/60001msec)
clat (usec): min=2, max=52565, avg=256.36, stdev=742.05
clat percentiles (usec):
| 99.90th=[10683], 99.99th=[25297]
Disk stats (read/write):
vda: ios=99704/99652, sectors=797632/797273, util=87.57%
After opening a ticket, I was migrated to another node, this time with a 7443P. While the disk was slightly improved, CPU performance on this node was extremely poor, with steal time up to 90% while running Geekbench 6.
Geekbench 6 score of 393 Single Core, 676 Multi Core
I opened another ticket, and was moved to another node. While the CPU performance was better, multicore performance was not as expected: 834 Single Core, 989 Multi Core.
The larger issue, however, was the still extremely poor disk performance. Below is the latest YABS from this morning:
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
# Yet-Another-Bench-Script #
# v2026-05-11 #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
Sat May 16 07:47:34 AM UTC 2026
Basic System Information:
---------------------------------
Uptime : 1 days, 1 hours, 7 minutes
Processor : AMD EPYC 7763 64-Core Processor
CPU cores : 2 @ 2449.998 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM : 3.8 GiB
Swap : 4.0 GiB
Disk : 49.9 GiB
Distro : AlmaLinux 10.1 (Heliotrope Lion)
Kernel : 6.12.0-124.55.3.el10_1.x86_64
VM Type : KVM
IPv4/IPv6 : ✔ Online / ✔ Online
IPv6 Network Information:
---------------------------------
ISP : Servitro LTD
ASN : AS213495 SERVITRO LTD
Host : Servitro LTD
Location : London, England (ENG)
Country : United Kingdom
fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda4):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 42.66 MB/s (10.6k) | 174.59 MB/s (2.7k)
Write | 42.73 MB/s (10.6k) | 175.51 MB/s (2.7k)
Total | 85.40 MB/s (21.3k) | 350.10 MB/s (5.4k)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 31.56 MB/s (61) | 36.03 MB/s (35)
Write | 33.70 MB/s (65) | 38.61 MB/s (37)
Total | 65.26 MB/s (126) | 74.65 MB/s (72)
iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | busy | 440 Mbits/sec | 19.9 ms
Eranium | Amsterdam, NL (100G) | 3.37 Gbits/sec | 3.00 Gbits/sec | 7.54 ms
Uztelecom | Tashkent, UZ (10G) | 330 Mbits/sec | 1.40 Gbits/sec | 95.9 ms
Leaseweb | Singapore, SG (10G) | 937 Mbits/sec | 627 Mbits/sec | 161 ms
Clouvider | Los Angeles, CA, US (10G) | 668 Mbits/sec | 133 Mbits/sec | 148 ms
Leaseweb | NYC, NY, US (10G) | 1.94 Gbits/sec | 1.32 Gbits/sec | --
Edgoo | Sao Paulo, BR (1G) | 863 Mbits/sec | 708 Mbits/sec | 189 ms
iperf3 Network Speed Tests (IPv6):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 4.29 Gbits/sec | 2.65 Gbits/sec | 12.1 ms
Eranium | Amsterdam, NL (100G) | 3.80 Gbits/sec | 2.87 Gbits/sec | 6.62 ms
Uztelecom | Tashkent, UZ (10G) | 1.01 Gbits/sec | 438 Mbits/sec | --
Leaseweb | Singapore, SG (10G) | 552 Mbits/sec | 1.05 Gbits/sec | --
Clouvider | Los Angeles, CA, US (10G) | 1.15 Gbits/sec | busy | 148 ms
Leaseweb | NYC, NY, US (10G) | 2.15 Gbits/sec | 1.25 Gbits/sec | --
Edgoo | Sao Paulo, BR (1G) | 873 Mbits/sec | 933 Mbits/sec | 189 ms
Geekbench 6 Benchmark Test:
---------------------------------
Test | Value
|
Single Core |
Multi Core |
Full Test | https://browser.geekbench.com/v6/cpu/18013023
YABS completed in 30 min 47 sec
Note: The YABS geolocation says London, but the VPS was being advertised as being in Frankfurt. I'm not sure why it shows London.
I also noticed these kernel watchdog messages:
[root@109 ~]#
Message from syslogd@localhost at May 15 23:27:35 ...
kernel:watchdog: BUG: soft lockup - CPU#0 stuck for 76s! [kworker/u513:4:11703]
Message from syslogd@localhost at May 16 02:01:55 ...
kernel:watchdog: BUG: soft lockup - CPU#0 stuck for 54s! [crond:808]
Message from syslogd@localhost at May 16 04:53:58 ...
kernel:watchdog: BUG: soft lockup - CPU#1 stuck for 96s! [unix_chkpwd:14221]
Message from syslogd@localhost at May 16 05:13:19 ...
kernel:watchdog: BUG: soft lockup - CPU#0 stuck for 163s! [swapper/0:0]
[root@109 ~]#
Message from syslogd@localhost at May 16 08:02:33 ...
kernel:watchdog: BUG: soft lockup - CPU#1 stuck for 29s! [geekbench_avx2:17243]
Message from syslogd@localhost at May 16 08:08:33 ...
kernel:watchdog: BUG: soft lockup - CPU#1 stuck for 37s! [geekbench_avx2:17243]
Message from syslogd@localhost at May 16 08:16:04 ...
kernel:watchdog: BUG: soft lockup - CPU#0 stuck for 48s! [geekbench_avx2:17243]
It seems like this provider is massively overselling their capacity. Is anyone else experiencing similar issues on their Frankfurt services?
Comments
Same problem here. The disk speed was quite low, migrating to another hypervisor fixed it, two weeks later the disk speed became low again, migrating again didn't help. I also suspect that the company only has one customer service person named W.M. (out of respect for privacy, the full name is not printed)
Same here. Service cancelled, waiting for a refund.
I've had my ServItro service since 2025-06 and it's been extremely unreliable. Would not recommend.
It's a daily occurence of having very intermittent network. At the start IPv6 did not work, that was shortly fixed per ticket. As of right now, IPv6 doesn't work again.
The CPU/disk occasionally gets unusably slow. Like @custard8084 said there's likely only one customer service person and downtime tickets get left for 4d+.
I likely can't let this year continue without migrating my services off.
I've requested a cancellation and refund.
me too! same issue, no one response ticket!
@Servitro
Hello,
I agree with the points raised. Please be assured that we are continuously migrating servers to other hypervisors upon request to ensure stability.
I have also attached a screenshot for your reference, which clearly demonstrates that there is no CPU host overload at this time.
Our team is working around the clock to resolve the remaining issues on the host, and we expect everything to be sorted out ASAP. We appreciate your patience while we finalize these fixes.
https://browser.geekbench.com/v6/cpu/18024780
Hi
We are working to resolve this
You also work to resolve the outages. When will you start with that work ? Monday, I suppose?
not RAID 10
@Servitro
I hope you also work on my refund request.
Yeah also tried them. Didn't expect much, unusable for me. Waiting for my 7days money back guarantee.
Sure
@Servitro
@Servitro
Still no response to any of my three open tickets and still no refund.
My hope was to find a nice provider, but now I think I will need to contact PayPal for a refund.
It should not be that hard to answer tickets and initiate a refund, especially when you advertise 24/7 support and 7-Day Money-Back Guarantee.
Please check Ticket #MNJ-297414."
They closed my Ticket BOA-978892 without response.
@Servitro
Dear Users,
We are getting complaints of servers having high CPU stealing and very slow disk speed. As a justification, I assure you that we don't overallocate the hypervisor CPU at all.
The issue is because of overprovisioned servers on one hypervisor (overused disk and swap), causing these frequent disconnections and timeouts.
Rest assured, we have added more hypervisors to our infrastructure, and we will migrate the servers to the new host starting in the next 24 hours. Also, I will compensate users for the problems caused.
Thank you for your patience.
wow that's a huge CPU Steal.
Price talks.
@Servitro And the outages still persist, it's time to say goodbye to these guys also.
@Servitro Was the hypervisor added? Still getting poor multicore. https://browser.geekbench.com/v6/cpu/18060914
Adding a Frankfurt data point since you asked -- same symptoms, and getting
worse, not better.
Two VPS on two different Frankfurt nodes, both Debian 13, both on the
"double CPU/disk" promo (2 vCores each):
- "$1 Server" (0.9 GB / 20 GB, $12/yr) -- ServerVerify grade F:
https://serververify.com/benchmarks/4597e4be-9f15-4ff4-8268-ba5e3d95f4f4
- "Virtual-1" 7763 (3.8 GB / 50 GB, $20/yr) -- ServerVerify grade
https://serververify.com/benchmarks/5cf2f28c-f1c3-476a-8fb5-e426b55974f0
Both show the exact signature you posted -- multi-minute freezes where the guest
gets no CPU/timer time: RCU stalls, "timer wakeup didn't happen", systemd
watchdog timeouts, and:
~25 and ~23 episodes over the last 7 days, basically daily, including this
morning. And it's on two separate nodes at once -- so much for "one bad
hypervisor"; the migration promised on May 18 changed nothing here.
Disk matches your complaint too, all via YABS/fio: 1M mixed R/W is 27.6/30.1
MB/s on the 4 GB box and 43.1/45.7 on the 1 GB box, large-block IOPS in the tens
-- and unstable run to run (the 4 GB box's 1M halved vs the ServerVerify run
above). GB6 single-core 627 is about half a healthy 7763 core; the bench itself
ate steal.
The lockups also happen at idle (load ~0, free RAM), so it isn't my workload --
which fits their own "overused disk and swap" admission. Note average steal
reads low (<0.5%): during a freeze the guest clock doesn't advance to accrue
steal ticks, so the soft-lockup signature is the real tell, not the steal %.
(And the "London" geolocation is just a GeoIP error on their ranges -- routing
puts both boxes firmly in Frankfurt.)
Bottom line: I've given up on both. Completely unusable, and at $12+$20/yr I've
written the money off rather than chase a refund through the same dead ticket
queue everyone here is stuck in. Reads like a straight oversell-and-ignore scam
to me -- buyer beware.
Performance is significantly better now.
I hope it remains consistent over time.
I've had a server with this provider since last summer (Virtual servers - AMD EPYC 7443P - Frankfurt - Virtual-1).
I can recall three significant instances where the servers were completely unavailable for extended periods (from 6 to 24+ hours). Ticket responses typically arrive in less than 24 hours (the average response time for all my tickets is about 7 hours).
According to Uptime Kuma statistics, server availability over the past six months is 98 percent, but there are also 8 pages (10 events per page) of network drop events.
I haven't requested node changes or anything like that from the provider; this benchmark was run about an hour ago and displays the current performance of my node.
Regarding London's display in the benchmark, I think it's an error on the part of the location service, or they're relying on IPv6, which is assigned to the UK.
https://bgp.tools/as/213495#prefixes
My data plan expires in a month and a half, and at this point, I'm not sure I'll renew.
Perhaps $20 per year for 2 vCPUs and 4 GB of RAM is a good deal, but network stability is extremely disappointing.
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
Yet-Another-Bench-Script
v2026-05-11
https://github.com/masonr/yet-another-bench-script
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
Sat May 23 20:48:06 BST 2026
Basic System Information:
Uptime : 31 days, 14 hours, 33 minutes
Processor : AMD EPYC 7763 64-Core Processor
CPU cores : 2 @ 2449.998 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ✔ Enabled
RAM : 3.8 GiB
Swap : 512.0 MiB
Disk : 48.4 GiB
Distro : Ubuntu 22.04.5 LTS
Kernel : 5.15.0-176-generic
VM Type : KVM
IPv4/IPv6 : ✔ Online / ✔ Online
IPv6 Network Information:
ISP : Servitro LTD
ASN : AS213495 SERVITRO LTD
Host : Servitro LTD
Location : London, England (ENG)
Country : United Kingdom
fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1):
iperf3 Network Speed Tests (IPv4):
iperf3 Network Speed Tests (IPv6):
Geekbench 6 Benchmark Test:
Test | Value
|
Single Core |
Multi Core |
Full Test | https://browser.geekbench.com/v6/cpu/18099594
YABS completed in 26 min 33 sec
Update — both my VMs got migrated and the problems are gone.
Following up on my earlier (pretty negative) post: I opened a migration ticket as Servitro suggested, and on May 25th both of my VMs were moved to a new hypervisor (~2h20 of downtime each, came back on fresh hardware — one is now on an EPYC 7443P).
Results after ~1.5 days on the new host:
So credit where it's due: the new hypervisors are healthy and the migration genuinely fixed it. The catch is you have to actively chase it via a ticket — it doesn't happen automatically — but once migrated, both VMs are fully usable again. Walking back my earlier "oversell-and-ignore" verdict for my own case.