All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Melbicom - absolutely terrible experience (KVM1, Vilnius)
jasontresize
Member
I was told "no refunds" 3 times, even though this company finally admitted their VPS is massively oversold and non usable. Keystroke is so bad it took up to 2 minutes - if it didnt drop the ssh in that time. Support's attitude was a "prove it" style. So I did.
My last support message was: "Together with the technical department, we performed tests, according to the results of which we inform you that there are no problems on our part.
In addition, we can confirm that the host node on which the virtual server is located is not loaded."
Terrible communications, lack of accountability, "we cant" attitude.Results for: sysbench cpu, sysbench memory and a network ping listed below. It is 1vcpu/2gb ram and 20gb hdd. The numbers speak for themselves, use at your own peril 
@NexOasis
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 349.87
General statistics:
total time: 10.0014s
total number of events: 3500
Latency (ms):
min: 2.73
avg: 2.86
max: 8.47
95th percentile: 3.02
sum: 9993.81
Threads fairness:
events (avg/stddev): 3500.0000/0.00
execution time (avg/stddev): 9.9938/0.00
Threads started!
Total operations: 4096 (13334.56 per second)
4096.00 MiB transferred (13334.56 MiB/sec)
General statistics:
total time: 0.3051s
total number of events: 4096
Latency (ms):
min: 0.06
avg: 0.07
max: 0.40
95th percentile: 0.12
sum: 302.08
Threads fairness:
events (avg/stddev): 4096.0000/0.00
execution time (avg/stddev): 0.3021/0.00
--- 195.238.126.196 ping statistics ---
102 packets transmitted, 21 received, 79.4118% packet loss, time 102811ms
rtt min/avg/max/mdev = 33.271/33.633/34.164/0.269 ms
Comments
hdd? as main system drive? in this day and age? come on
Also, how much did you pay for it and where was it located?
Oh I forgot the location! In Vilnius. It's their VPS1 product
@jasontresize
Your ticket has been passed to billing for a refund, and if not already, you shall get an answer shortly.
On the technical side: when you reported the issue, our team tested both the VM and the host node and couldn't reproduce it. The benchmarks you posted point the same way. The CPU run is stable (2.86 ms average latency, 8.47 ms max, no thread variance), and memory throughput is normal for an entry-level 1 vCPU plan. Neither shows the instability you'd see on a congested node.
The one result that stands out is the packet loss. We couldn't reproduce it from our side. Your ping shows a flat RTT (33–34 ms) despite the loss, which usually points to a problem somewhere along the network path rather than on the server. If you can share an MTR in both directions (your connection → VM and VM → your IP), we'd be happy to look at the route and take it up upstream assuming the loss is on a hop we can influence. You can be sure that we take technical matters seriously and we would actually welcome your answer on this matter.
To correct a couple of points in the thread: the disk on this plan is NVMe SSD, not HDD, and we do not overcommit our nodes.
Whatever the cause, you couldn't use the server the way you needed to and we are very sorry that the experience differs from what we intend and we will be in touch shortly to make it right by you.