New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Yep, will go right at it (kinda, hey, it's weekend ... *g)
And thanks for the c1v bonus. I actually was a bit horrified by the idea to throw a significantly heavier load at it and the w..a..i..t..i..n..g for it to finish!
But no, not 10 and 25 times bigger. Only about 20 times more records - but that in two versions, batches of 50 and batches of 6 (which happens to stay under 4KB * wink wink nudge nudge)
I think by tomorrow you'll see the results.
And I generally run FreeBSD on my servers. But thanks for your kind offer!
what version of FreeBSD you need on the vps
What type of app/service is that? a VPN server? I mean, the disk IO was crappy
14.0
But hey, why not wait for a Racknerd reaction? I mean switching the OS just for a quick benchmark? Really?
I don't feel well with that. Even if Racknerd/ @dustinc doesn't react and give me access for a few days, so what? I mean it's not like a Racknerd result is a sine qua non.
I haven't decided that yet, but probably an NS server, maybe even a small web server (with memory cache). Or maybe even additionally a VPN, I really don't know yet. There are many things one can use that thingy for, especially with 2 GB memory. It's a nice little box even though its disk is meh.
I ran the same tests across a range of my ~$10/year VMs all with roughly the same specs (1 core and 1.5-2GB of memory). MassiveGrid ranked 5th in CPU performance which is a decent result since it is the lowest price of all the providers. However, it not only came in last place for disk performance it was almost 13x slower than the next slowest provider. Other than the initial install of the operating system taking quite a bit longer than it normally does I don't really notice the low disk performance for my workload. It would certainly be nice to have higher throughput but everything works well enough as is.
ProviderA 572Mbytes/sec
ProviderB 495Mbytes/sec
ProviderC 342Mbytes/sec
ProviderD 318Mbytes/sec
ProviderE 315Mbytes/sec
ProviderF 310Mbytes/sec
ProviderG 305Mbytes/sec
ProviderH 264Mbytes/sec
ProviderK 204Mbytes/sec
MassiveGrid 16Mbytes/sec
educated guess, dd with bs=16k
It's understood that even with 1M it be last place, but you'll reach something above 100MB/s after all. Could of course all be higher and better and whatnot. But for $6 a year I would say it's doing good.
As you pointed out yourself, some of your VMs which cost nearly twice as much are worse in other regards, CPU performance for instance.
How about doing a real world comparison and timing something that involved disk snd cpu and eventually even network?
For example borg-backup on a folder of a few GBs of all different kind of files, types and sizes? Needs reading and writing as much as cpu power for encryption.
@Falzo and others interested
Done. In the same order as before and on the same VMs (minus c1v):
Remarks/Notes:
all VMs did 946875 records and the .db file size was 555,454,464 bytes
(without c1v) only the host_c VM has a separate storage drive (spinning rust) and it was that drive I used for the benchmark
'Bo50' means "batch of 50" (records per commit), 'Bo6' means 6 records per commit, which just so happens to be under 4KB, while Bo50 (just like in the benchmark before) is about 30KB per commit.
times are microsecond precise and written in a, I hope, easier readable format
Like with the benchmark before no tricks or SQLite optimizations were used.
With Bo50 and almost 1 Mio records total, so a bit under 20 times the number of records of the last benchmark, my old box VM is somewhat slower than the massiveGrid VM, but with Bo6 that is, much much more commits but smaller ones, the mG box falls back and needs almost twice as long as my old box VM (which confirms what I said earlier: yesterdays parameters actually were advantageous for mG). Driving the mG VM hard with many small commits - which is what DBs typically do - it looks even worse.
And the host_c storage drive (not the boot SSD or NVMe!) blows both of the other two VMs out of the water.
So, my original remark that the massiveGrid VPS has a crappy disk not fit for DB (or other disk-heavy) jobs stands with even stronger confirmation now.
If you are really, really interested, @Falzo and think it would bring significant new insights, I'd be willing to run one last benchmark (tomorrow) with about 2 Mio records, which should work OK as all VMs have 2 GB memory, but frankly, I'd prefer not to. Simple reason: lots of waiting while those test run. Let me know what you think.
@MassiveGRID VPS even the 4x vCore VPS will struggle with 100 million data rows query.
If I have to use VPS for VPN , then cheaper NAT ipv4 with 10 gig data port is much better option. Hint AKH
Just a benchmark on MassiveGrid to verify CPU performance itself will be great i.e. using Ramdisk.
Nope, I went with bs=1m to give MassiveGrid the best possible outcome. My MassiveGrid VM is $7.07/year because I opted for the extra memory (2GB vs 1GB). And yes, I totally agree for just over $7/year I am very happy with the results. I do think they should probably increase the iops value so you don't have as many people complaining about disk performance but even if nothing changes I'm happy with my purchase.
MassiveGrid is the cheapest but not by double. A few others are $8/year but most of them are exactly $10/year and the most expensive one is $11.69/year.
Yeah, there are lots of additional testing that could be done that would equate to a more useful result but I just wanted a quick and dirty test to show anyone that if they are looking for a super fast disk VM then this probably isn't the one for them. However for a mail server, web server, VPN server, hell even backup server (who cares if it takes 5 mins to complete vs 30 seconds, it is a fucking backup) this is a pretty great option. At least I think so but your milage may vary.
🤷🏻♂️ maybe you are just unlucky then.
PS: forgot the direct flag. Also changed it to sync and an even bigger size...
@jsg thanks a lot for your efforts. I think the more data you have the better it can be judged upon.
The difference between bo50 and bo6 is a perfect example. While the (presumably heavily cached) host_c scales easily and does not reach any limits of whatever is under the hood but in front of those harddrives your dedi ssd seems to have run out of that with a more sequential load. But on the other hand with small blocks it can again easily outperform the hard capped VM.
No need for more tests inless you are self interested in widening the view even more.
I do think in the end all this proves both our opinions. Yes, VMs that don't reach more than 1k IOps and 150MB/s writes are not a good choice for a filebased database with millions of rows and operations.
In my eyes this use case alone does not make it a crappy disk though. Webtropia and contabo implement similar limits only a bit higher at around 5k if I remember correctly. Those have been called out too for a while ;-)
Yet it again comes down to expectation management as usual. Choosing sql-lite for something that requires millions of rows that are accessed and changed frequently is a poor choice to begin with. 1990 just called...
Putting that on a 50cent VM and complaining about poor performance - dunno what one should call that 🤣
I totally agree with you once more. This VM is totally worth it, with lot's of use cases. File based databases not being one.
Yeah, it doesn't matter what settings I change with the dd command the results are pretty much the same for me. The only time I saw better results was when MassiveGrid increased my Proxmox iops value from 1k to a higher amount. I did the exact same test across all 10 providers VMs though so if only one of them gets poor results I don't think it is an issue with the options I used (9 out of 10 performed as expected). Maybe there are some other differences between the NY cluster and your's? Regardless, not a big deal to me.
Yeah, that's highly likely then.
Yep, that's why I collect so many (not just in this DB benchmark but generally), show both, buffered and sync'd, tell about nowadays (with httpS everywhere) important AES and RSA key gen. performance, show (sometimes dumb) single core as well as two versions of multicore, etc. ... and then compile a report from many runs.
I'm not so sure about that.
Nope, it's not that simple. You see, no matter how hard a provider tries to avoid caching, at the end of the day some caching is pretty much always going on, e.g. by the drives themselves, by the guest OS, by the controller, ... Just too many layers involved.
Also virtualizer A != virtualizer B and they can be bitches, among others wrt caching. As I happened to occasionally run benchmarks (and also currently do) on demand for providers to hunt down some (usually performance related) problems or to simply test some new node hw or config, or ... I've gained a bit of insight into their perspective as well as problems, issues, and/or quirks of virtualizers, host OSs, etc.
And I've in fact seen VMs run faster with virtualizer caching disabled or changed to a different type.
And of course also the OS I always use on servers ([some]BSD, usually FreeBSD) does some caching, although way less aggressively than lin-we-hate-Russians-ux (which is why I hardly care about results there. And yes, I do have a version of my program for li-sanctions-ix as well, and could and did compare the results on the very same node) but at least on FreeBSD "do sync'd writes!" actually works, which is helpful when judging some node config.
Thanks, no. I think I've proven my original statement *g (but there's kind of a 'but', read on)
I agree for the sake of keeping this friendly and peaceful.
Which 1k IOps? I saw a bit over 200, and ca. 250 max. And that IOps is based on 4KB blocks and 4 threads. The throughput with that was less than 1 MB/s, but granted it was based on seq. writes which is a weak point for many VMs, because rapidly throwing 64k sync. seq. write requests each from 4 threads at it pretty much shuts down the disks, controllers, and usually even the virtualizers opportunity to do readaheads (which is one the reasons I do it).
But OK, my benchmarking maybe fell in a time window that was unlucky for massiveGrid. I'm absolutely willing to repeat my benchmarking at another point in time (and will report back any significant changes possibly found).
About Webtropia I don't know a lot but, yes, about Contabo getting bashed I know. And while I frankly don't care much because my loyalty with our community LET and not with this or that provider, I can't confirm them being ignorant or even ill-willed, based on my experience. In fact I personally experienced them being concerned about some allegations and more interestingly, even about potential issues. I was multiple times asked for my view or to hunt down suspected weaknesses, compare this SSD vs. that SSD they considered using, etc. And it was really evident that they listened attentatively and really did care. I also was under the impression that when I contacted anyone with detail questions they either were under order or simply were open and had the good will to answer fully and well detailed to what I asked them. There simply was no hide and seek or stupid games played.
On the other hand Contabo is a company and has to make profit so they simply can not offer the best of the best for a low price; compromises have to be made. But all in all, at least back then (when I was in contact with them) I was under the clear impression that they really and honestly tried to offer the best that was feasible for the price.
I btw. still have a few Contabo VPS and I still like them.
But be that as it may: thank you for lighting up an idea in my head! I'll run exactly that DB benchmark that I ran on mG, my host_c storage VM, etc. on one of my Contabo VMs too! Then we'll have tangible data we can think and talk about.
I disagree. Do not underestimate SQLite. It's in fact my preferred choice for that kind of use case. And it's more than sufficiently fast for many, many use cases at which others throw MySql or some other "real SQL DB".
I'll limit myself to one single reason here: Besides the fact that when pondering a concrete serious and heavy load large DB one shouldn't look at this or that software only but at the "complete package" i.e. the hardware, the OS, and the SQL server, many ignore an actually relevant and important question: how does the "front end" program say, a web server app communicate and transfer data to/fro the DB? Because that not only is a common source of trouble or even problems but it also can be (and often is) very performance relevant! For example, simply using UNIX ("deamon") sockets rather than TCP sockets can dramatically improve performance.
With SQLite no fuzz, you are in full and direct control and if you are so inclined (or under pressure) you even can simply call deeper layers.
I'd use SQLite for a billion rows without blinking an eye if the DB structure, kind of task, and parameters allow for it.
So, do not needlessly put the SQL server on another box and don't just look a SQL server performance but at the effective performance of the whole packet that is, how fast can you effectively get how much data into and out from your application?
The DB interacting part of my small DB benchmark is not in any way optimized and not even written in a compiled language. But who cares as long as everything is equal for all VMs tested. It's also way slower than an optimized app in a serious (compiled) language would be. But who cares, this test was not about how fast a DB can be but about relative performance of the tested VMs with a given DB load.
"a comparative benchmark", simple. Btw, it wasn't millions (plural) of rows, it was a bit under one (1) million rows - upon request.
Nope, anything heavily using the disk. "file based DB" was just a kind of hardcore test case to find out whether my original assertion/"verdict" was correct or not. I found it clearly confirmed, that disk is crappy - BUT: yes, that disk is on a dirt cheap VM and for less than $1 per month one can expect only so much.
All in all, yes, we are in agreement. That @MassiveGRID promo indeed is an excellent deal and I'll repeat myself yet again, I really like my little mG VPS. And extra kudos for tolerating all my benchmarking like a docile lamb without any sign of unhappiness! That VM just took it without so much as a little hiccup.
... and Done.
These are the results achieved by/on my Contabo VPS (4C8GB, sorry but I have none smaller) with exactly the same parameters, number of records, etc as with the other tests.
Bo50: 45 s 440.6 ms, Bo6: 275 s 950.5 ms
Note: This VPS has no storage drive so the benchmark was run on the SSD.
So, a bit slower than host_c in Bo50, and significantly slower than host_c in Bo6, but very significantly (up to 10x) faster than both, the mG and my old box VM.
Not outperforming a, granted very fast, spinning rust disk (+ evidently very smart RAID, config, etc) is certainly not bragging material but it seems the rumors of how oh so bad and crappy Contabo is and how bad the SSDs are, are quite exaggerated.
Again, thanks for triggering me to simply run the DB benchmark on the Contabo VPS too!
I also see 200-250 iops with 4kb & 4 threads via fio, which is definitely worse than average
It's avg. $6.5/yr vps and it only makes sense to get it with a 4 yr contract (if you believe they will last for 4 years). If you got it for 1 year - you lose, there's enough offers that are better bang for the buck for $10-14/yr.
Also MassiveGRID said you will be able to raise iops limit for some $.
Uhm, how about a quick look at the OP of this thread?
MassiveGRID told in one of the threads earlier that they don't provide IPv6 currently but will add it at some point.
In their Frankfurt, DE location I started wondering today why my eth0 had IPv6 that looked like a public address. First I thought they had proceeded with the IPv6 setup quickly. However it turned out there wasn't connectivity. On closer look the prefix looked like HE tunnelbroker prefix. I hadn't done anything myself to enable IPv6 (i.e. not my tunnel). Everything IPv6 related was at OS defaults.
Out of curiosity I wanted to check the IPv6 router situation by checking who is responding at ff02::2. Turns out there are a lot of folks in the same L2 network segment who think they are IPv6 routers:
So, in case anyone else got an IPv6 to your VPS and are wondering the same... this is the reason.
Quite unfortunate. I suppose lots of folks established IPv6 tunnels and misconfigured it so that they are now announcing willingness to route other customers' traffic via those tunnels.
As a quick remedy, I added the following in my
/etc/sysctl.conf:Looks like MassiveGRID should do something to prevent the impact of such fake routers. They should possibly implement IPv6 RA guard or similar or reconsider the network architecture. This is a security problem because any one of those fake routers could be forwarding and intercepting other customers' IPv6 traffic for some nefarious purposes.
(Sorry, can't be bothered to open a ticket as I resolved it for myself already.)
Hello,
I decided to purchase a VPS server from Contabo, so I searched for "Contabo status" on Google to check for any recent updates about their service status before making the purchase. However, I ended up on a promotional page on massivegrid.com, where they offered a special deal for Contabo users, but the page contained negative feedback about Contabo.
Despite this, I bought two servers through the promotion because the prices were very cheap. Unfortunately, after a few days of use, I noticed that the servers were frequently going offline. I set up a ping service to monitor their availability and found that the servers were going offline almost every day.
I contacted their support, and they changed the location of one server from Germany to the UK, but the issue persisted. After several more days with brief outages of 10-20 minutes almost daily, the second server in Germany went offline for almost 3 hours. Their support team explained that the power was shut down, there were network issues, and other problems.
How can a company like this not have alternative power sources in place? I used the service for about a month and a half and requested compensation for the last month due to the repeated outages, but they refused.
Can you provide a link, please?
Huh? Contabo has a location in the UK? Can you tell us more?
massivegrid.com and my server account down along time
high unavailability soon
Looks more like they started their carrier months ago, not years and try to figure out, how the technology works today.
my servers down and their website down most of the time
its so strange and incredible for a datacenter
Yes, there seems to be a problem, my VPS is down, or more precisely, unreachable too.
I'm willing though to calmly wait till monday evening. I mean, (a) it's weekend, and (b) we've seen even way more expensive providers who can't or at least don't solve major problems during weekends.
Benchmark and review of the DE, FRA VPS and a re-review of the UK, LON one.
First, as there are some significant changes the UK, LON one, based on a bit over 50 runs.
Processor & memory
(emphasis are changes)
A quite significant change in performance compared to my first benchmark, especially wrt AES (which nowadays is quite important) which now is almost double the speed!
now the disk
Sorry but I see no other way to put it than to say that they managed to turn from crappy to to really shitty (a bit less than half the speed compared to the first benchmark). Yuck!
The network wasn't retested.
TL;DR Basically processor & memory performance significantly increased (AES basically doubled) but disk performance cut down to half. I'm not sure that I consider that a positive evolution ...
Now, on to the DE, FRA VPS (again a 1 vCore, 2 GB memory one), based on 39 runs.
Again, processor & memory first
I feel that the right way to put it is "Wow, they managed to offer a VPS whose processor & memory performance is even crappier than the London one was when I first benchmarked it.
Now on to the disk
Wow, much faster than the crappy London disk, by no means even vaguely fast, but at least not bottom of the barrel crappy. Maybe I'll even run my DB benchmark on it.
Finally connectivity
Granted, my selection of targets isn't the best one and also somewhat limited, but the results confirm that my thinking was right: As kind of expected only the big targets within Europe worked somewhat useably. Funnily, both russian targets were working well, but otherwise if you need a VPS with at least some global visibility, STAY AWAY!
But of course one also must see that what one pays pretty much is the price of an IP4 (and cheap at that). So, if approaching it from that angle ("Hey, I pay for a cheap IP4 and get some proc&mem., albeit not good one, and some disk space, albeit crappy thrown in for free!"). Plus, though I don't really see how one could use it up (in DE, FRA anyway) one also get a very generous amount of traffic on top!
TL;DR I do not regret having purchased the London MG VPS, but I really do regret the DE, FRA one.
Probably I'll run my DB benchmark on both VMs as well, just for fun.
there are so many simple ways to block ND and RA that I have no words for it, and yes, at VPS level, not even port or switching level.
THX @tiitae on the info provided.