Linode SSD Beta(forum.linode.com)
forum.linode.com
Linode SSD Beta
https://forum.linode.com/viewtopic.php?f=26&t=10406
80 comments
Well, I've been using it for over an year now. Yes, it does really speed up things. I've found out that people grossly over estimate need for SSD space. I'm using 64 GB SSD with 3TB drive and hard disk is really rearely touched. I've even enabled power saving spin down for it, so I know when it starts. In normal daily usage HDD isn't being touched at all. It's only when something like linux updates are being run or so. I've also enabled write-back caching without maximum time limit. If you use write-through caching it naturally causes HDD to run all the time. I've chosen to cache everything, not only random reads. Because I have plenty of space with 64 GB SSD. I don't know what people are doing who claim thei need larger SSD than that. Maybe they're working with large data sets or have absolutely massive games or so. As summary, yes, I love it. SSD is never full, I'm not running out of disk space and yes, I do get pure SSD performance over 99% of the time. Only if I pickup some movies or music which has been around for months without being accessed then there's HDD access of course.
Setup was ok, because I did it when I replaced my computer so I built everything from scratch anyway. I'm going to blog about that, but I have huge backlog of stuff to get blogged. P.S. Some cache vendors (like Seagate Hybrids drives) recommend using write-through caching, because in the case SSD dies, you'll still have fully working file system on HDD. With write-through caching, things are going to be very badly messed up if SSD dies. Practically totally unrecoverable situation. But that's why we got backups, right?
"With write-through caching, things are going to be very badly messed up if SSD dies"
You probably meant the reverse of that (With write-back caching... etc.).
You probably meant the reverse of that (With write-back caching... etc.).
Yep, true.
64GB SSDs aren't large enough to take full advantage of the wide data paths offered by modern SSD controllers that stripe accesses across many flash chips. Going up to at least 256GB is usually necessary to get the full speed possible from having every channel populated.
http://www.anandtech.com/bench/product/752?vs=750
http://www.anandtech.com/bench/product/752?vs=750
For most applications you wont notice
If you're building a server and spending money to put a SSD in front of hard drives because you want throughput, it behooves you to consider throughput/$.
Maybe you'll notice, maybe you wont. There's a place for good enough, and any front-SSD cache will be a huge advance for sure over not. But I second the notion that you probably want to find a SSD that is performant, and low capacity ones often are heavily compromised in this department.
Maybe you'll notice, maybe you wont. There's a place for good enough, and any front-SSD cache will be a huge advance for sure over not. But I second the notion that you probably want to find a SSD that is performant, and low capacity ones often are heavily compromised in this department.
Generally the software will bottleneck before the drive. Its pretty hard to get rated performance out of an SSD. You need to keep the queue at pretty much full depth, which means aio or (much harder) threading. Most real world software at present gets nothing like SSD potential performance in real world situations, as it is mostly build for HDD where none of this stuff mattered.
Things I really wish they could add or improve.
PHPBB? What year is this? The Website design and structure seriously needs some thought and work. LongView, either have a trial only version of bump the free tier retention to 24 hours. What is the point of a 30 minutes graph? Get rid of the Add on, those pricing are just plain stupid. Give options to increase Memory without buying new plans for $10/GB at a maximum of double current capacity. So a $20 1GB plan could be increase to $30 2GB Memory with everything else the same $20 Plan. That should just make Linode competitive against DO. Linode CDN - A CDN coming from those 6 Linode DC with Data coming off your transfer pool. May be any Data served over CDN would count as triple the amount of data from your pool. SSD Speed up. From the Data on ServerBear, this new SSD tier is working as well as its competitors. I am sure the NodeBalancer could do with a price decrease or bump in concurrent connection.
DO has all of the above in the pipeline for releasing this year, so lets hope Linode react quicker.
PHPBB? What year is this? The Website design and structure seriously needs some thought and work. LongView, either have a trial only version of bump the free tier retention to 24 hours. What is the point of a 30 minutes graph? Get rid of the Add on, those pricing are just plain stupid. Give options to increase Memory without buying new plans for $10/GB at a maximum of double current capacity. So a $20 1GB plan could be increase to $30 2GB Memory with everything else the same $20 Plan. That should just make Linode competitive against DO. Linode CDN - A CDN coming from those 6 Linode DC with Data coming off your transfer pool. May be any Data served over CDN would count as triple the amount of data from your pool. SSD Speed up. From the Data on ServerBear, this new SSD tier is working as well as its competitors. I am sure the NodeBalancer could do with a price decrease or bump in concurrent connection.
DO has all of the above in the pipeline for releasing this year, so lets hope Linode react quicker.
This sounds pretty cool! What sorts of considerations does one make when you are deciding between more RAM or SSDs?
Random IO is processed first through the SSDs (the thing that they are really good at) while sequential IO short-cuts to the hard drives - which is pretty slick.
I'm curious, what do you use to develop something like that? Is it build on top of something? Built into the kernel? I wouldn't even know where to begin...
Random IO is processed first through the SSDs (the thing that they are really good at) while sequential IO short-cuts to the hard drives - which is pretty slick.
I'm curious, what do you use to develop something like that? Is it build on top of something? Built into the kernel? I wouldn't even know where to begin...
Hmm, my guess, working only from that description, would be that they've created a RAID-1 mirror with equal-sized SSD and spinning HD partitions... but are able to route reads based on the actual position of the spinning disk heads.
Then, 'random' reads will usually come from the SSD, but those that happen to be under-the-head (as most often in long sequential reads) would come from the HD.
I don't know if usual RAID software/controllers are already optimized for such wildly-different device response speeds (as opposed to uniform devices).
Then, 'random' reads will usually come from the SSD, but those that happen to be under-the-head (as most often in long sequential reads) would come from the HD.
I don't know if usual RAID software/controllers are already optimized for such wildly-different device response speeds (as opposed to uniform devices).
Sounds like SSD's are used as a cache, like ZFS does with its l2arc.
For Linux specifically, there are https://github.com/mingzhao/dm-cache and http://bcache.evilpiepirate.org/ as well, which let you use arbitrary filesystems on top. I would bet that Linode is using one or the other of these.
Does ZFS use some sort of last-used eviction to purge the cache? It seems like differentiating between random/sequential IO is a bit different than LRU.
The design is documented here: https://github.com/zfsonlinux/zfs/blob/master/module/zfs/arc...
This looks like something you can accomplish with md raid: http://tansi.info/hybrid/
andrewcooke mentioned bcache, which is now included in the Linux kernel at of 3.10. Outside of that there are a number of storage cards and software products that offer this functionality now (essentially automatically tiered storage). For instance IBM has FlashCache, LSI has Nytro MegaRAID, and on and on.
Every time I think I'm done with Linode, they draw me right back in. I guess I'll wait to see about the pricing, but I imagine this will be a serious challenge for Digital Ocean to overcome, since their main selling point over Linode is cheap SSDs VPSs.
A staff member commented about pricing on the linked post after you commented this. Long story short, it won't cost anything and they're going to upgrade all existing servers eventually.
How is this a challenge to DigitalOcean? Linode's solution is inferior to the pure-SSD storage layout at DO and is still four times the price. Linode is trying (and failing) to play catch-up.
Waiting for digital ocean to give me some free upgrades =)
Have you been on Digital Ocean for a while? How do you like it so far?
I've been using them for a similar period as xur17.
Have not had a single issue, bar some packet routing at AMS1 that just lead to latency for a few minutes. Their API is getting quite nice to tie into, though I've had to resort to screen scraping for some of the newer options.
Have not had a single issue, bar some packet routing at AMS1 that just lead to latency for a few minutes. Their API is getting quite nice to tie into, though I've had to resort to screen scraping for some of the newer options.
I've been on Digital Ocean since the beginning of this year, and I have been very happy with it. I switched my main site over to them about 6 months ago, and haven't had any issues, and 0 (or very close to 0) downtime so far.
Wow, Thanks folks!
Looks like DO is earning their keep. I'm planning to move a forum off a shared host, so VPS was the first place I looked. They were recommended to me, but I only had one other first hand account of them until now.
Looks like DO is earning their keep. I'm planning to move a forum off a shared host, so VPS was the first place I looked. They were recommended to me, but I only had one other first hand account of them until now.
Sounds promising. SSDs have good potential as a cache for bigger backend spinning disks.
I know there is this theory that server hardware needs to be more durable therefore you should pay an order of magnitude more, but all of my server workloads are write somewhat frequently, read randomly, and delete almost never. It is my understanding, that commodity consumer SSDs should work fine for this workload.
I assume Digital Ocean is using consumer SSDs, and it feels like it shouldn't be a problem with the exception of the bad neighbor issue.
I assume Digital Ocean is using consumer SSDs, and it feels like it shouldn't be a problem with the exception of the bad neighbor issue.
Actually I thought it was going the other way: "Old school" is that server hardware should be reliable so it doesn't go down, and "New school" is that hardware should be cheap and there should be a lot of it so that if one server goes down we don't care.
Both DigitalOcean and Linode are in the "old school" camp. They are in the business of providing reliable hosting at good prices.
My question was along the lines of: Using consumer HDs in servers is a disaster because the 24/7 read workload eventually breaks spinning platters. Server grade magnetic disks are a must in servers. Consumer grade SSDs are acceptable in servers because they don't wear out from 24/7 reads. Consumer SSDs fail from constant deletes+writes. Server workloads don't produce many deletes, therefore it is safe to put consumer SSDs in servers.
Is the above correct? Is the premium for server grade SSDs a myth? Should I feel safe using Digital Ocean under the assumption they are using consumer SSDs for multi-tenant servers?
My question was along the lines of: Using consumer HDs in servers is a disaster because the 24/7 read workload eventually breaks spinning platters. Server grade magnetic disks are a must in servers. Consumer grade SSDs are acceptable in servers because they don't wear out from 24/7 reads. Consumer SSDs fail from constant deletes+writes. Server workloads don't produce many deletes, therefore it is safe to put consumer SSDs in servers.
Is the above correct? Is the premium for server grade SSDs a myth? Should I feel safe using Digital Ocean under the assumption they are using consumer SSDs for multi-tenant servers?
Some workloads are write-intensive and some aren't. For a hosting provider there's no way to know what the customers are going to do. I would expect that SSDs attract customers who are going to actually give them a workout, though.
> Some workloads are write-intensive and some aren't.
Did you read what I wrote? Do you mean delete-intensive?
Did you read what I wrote? Do you mean delete-intensive?
I don't think there's any truth to your notion that deletes are somehow worse for a solid state drive than other kinds of writes. Overwriting a sector has the same effect on longevity as erasing it and filling it up again, but in the latter case, you can use the ATA TRIM command to defer the flash block erase latency (which is significantly higher than the flash program latency). The only way in which deletes are "bad" is if you're comparing to a workload that fills the drive once and then moves on to fill a different drive - but that's not a fair comparison against doing all the writes to the same drive.
Different workloads can somewhat affect how much write amplification results from the wear leveling, but the best-case there actually is to have no long-lived data on the drive, ie. lots of deletes.
Different workloads can somewhat affect how much write amplification results from the wear leveling, but the best-case there actually is to have no long-lived data on the drive, ie. lots of deletes.
I think he's assuming that since it's actually rewritten flash-memory bits that degrade, if you don't delete data, then you don't rewrite. So without deletes, all writes simply fill more of the drive and you shouldn't see degradation.
Modern flash drives do indeed try to level the writes across all bits, but he's talking about work-loads that don't rewrite at all.
Modern flash drives do indeed try to level the writes across all bits, but he's talking about work-loads that don't rewrite at all.
I wouldn't call an application that writes once and never deletes anything on the hard drive a write-intensive workload. Filling up a SSD with write-once data means paying well over 50¢/GB for your writes, which isn't something you can do if you are "write-intensive" -- if you're writing 100x the capacity of the drive over its lifetime, then you are really write-intensive, at which point the distinction between delete-intensive and write-intensive is nearly nonexistent for obvious reasons.
All the dedicated server providers I know, do in fact use "consumer" HDs in systems, but allow you to spend more to use "server" HDs.
And, a properly equipped server for the workload being used, should not have its disks being used a lot, since loads tend to be spiky. So they should be busy during peak periods but much less busy other times.
And, a properly equipped server for the workload being used, should not have its disks being used a lot, since loads tend to be spiky. So they should be busy during peak periods but much less busy other times.
> They are in the business of providing reliable hosting at good prices.
Which is also possible in the "new school" camp…
Which is also possible in the "new school" camp…
[deleted]
Reading, writing, and deleting all degrade SSDs due to wear leveling. It's a common misconception that only deleting files degrades SSDs. I'm guessing this is what linode is getting at here.
Too late.
About 8 months too late.
About 8 months too late.
Too late for... ?
For me, at least.
I run a small blogging network. Linode have upgraded RAM, added cores, added disk space. They've done everything except improve random-access I/O, which is a major bottleneck for Wordpress installations thanks to MySQL's penchant for joining tables on disk regardless of indices.
I moved to DigitalOcean about 8 months ago simply to get access to SSDs. In most other respects I preferred Linode.
I run a small blogging network. Linode have upgraded RAM, added cores, added disk space. They've done everything except improve random-access I/O, which is a major bottleneck for Wordpress installations thanks to MySQL's penchant for joining tables on disk regardless of indices.
I moved to DigitalOcean about 8 months ago simply to get access to SSDs. In most other respects I preferred Linode.
You need a cache in front of Wordpress so that it doesn't hit the database on every read, then you can run Wordpress anywhere. I survived close to 3,000 req/sec against a Wordpress entry using a single Linode 360, back when those were available.
wp_supercache, nginx, varnish, etc. Rinse and repeat.
wp_supercache, nginx, varnish, etc. Rinse and repeat.
I appreciate the advice, but I knew this already. I've been using WP Supercache since it was released. Nginx for I think 4 years at this point. I have it configured to the point that nginx serves the gzipped pages WPSC writes out to disk without ever hitting PHP.
I have three words for you:
Recent.
Comments.
Widget.
I have three words for you:
Recent.
Comments.
Widget.
It's been a few years since I worked on a large WP install but I wonder if you could write a plugin that replaced the comments section with an esi (edge side include) directive. That would allow Varnish to cache the whole page and then call into WP using the url in you esi include to build the comments section. You could also then set the ttl on esi comments url so that you can fragment cache the comments for non-logged in users (for say 10 seconds).
More info here: https://www.varnish-cache.org/trac/wiki/ESIfeatures
More info here: https://www.varnish-cache.org/trac/wiki/ESIfeatures
It's funny you should mention this. I was chatting to a mate about this thread and he suggested using an ESI approach.
I think it would work well if the Recent Comments widget was modified to spit a HTML fragment to predictably-named files that varnish could pick up and include with ESI.
I think it would work well if the Recent Comments widget was modified to spit a HTML fragment to predictably-named files that varnish could pick up and include with ESI.
I never installed Wordpress in production, this is the first time I hear about ESI and in general have almost no relevant experience, but maybe this suggestion has some worth:
ESI sounds like it would couple your web application code to your cache. This sounds negative to my ear. How about modifying the Recent Comments widget to work with an IFRAME or some AJAX? It adds another request to the server, but now both requests can be cached and compressed.
ESI sounds like it would couple your web application code to your cache. This sounds negative to my ear. How about modifying the Recent Comments widget to work with an IFRAME or some AJAX? It adds another request to the server, but now both requests can be cached and compressed.
I wouldn't mind coupling Wordpress to Varnish, since I'm controlling my particular installation.
An ajax solution isn't a bad idea, though it would mean at least hitting PHP (whereas the Varnish option never gets that far).
An ajax solution isn't a bad idea, though it would mean at least hitting PHP (whereas the Varnish option never gets that far).
That's why Varnish is more effective, because you can configure it to cache the results of things that WP Supercache misses by design including the Recent Comments Widget and its data. If you need SSDs to run Wordpress, there's a flaw somewhere. Every time I've scaled Wordpress, caching has been the answer. Apply liberally.
WP Supercache is a hack anyway, for folks running WP on shared hosts without root. If you have root, there's a plethora of better things for caching, even as ancient as Squid as a reverse. You can get your MySQL traffic down to <1 QPS fairly trivially, no matter what kind of traffic is hitting the frontend.
Don't forget wordpress.com is a huge MU installation, and they've existed since before SSDs became popular. The disk is not your issue here.
WP Supercache is a hack anyway, for folks running WP on shared hosts without root. If you have root, there's a plethora of better things for caching, even as ancient as Squid as a reverse. You can get your MySQL traffic down to <1 QPS fairly trivially, no matter what kind of traffic is hitting the frontend.
Don't forget wordpress.com is a huge MU installation, and they've existed since before SSDs became popular. The disk is not your issue here.
Varnish is not effective in the face of Recent Comments because that widget breaks whole-page caching fatally. Every time anyone leaves a comment anywhere, the entire cache for the entire site is invalid.
When I looked at where the slow runtimes were occurring on Linode, it was always jammed on disk I/O and it was always on PHP functions that are reaching into MySQL.
In my experience the MySQL query cache + an object cache do more for sites with a Recent Comments widget than whole page caching.
As it happens, I do all of the above. And I was doing all of the above. And still getting jammed on I/O. Because MySQL likes to join on disk. Whole page caching is useful only if you prevent that from happening. It's useless if the cache is rendered invalid every few seconds on a chatty site.
When I looked at where the slow runtimes were occurring on Linode, it was always jammed on disk I/O and it was always on PHP functions that are reaching into MySQL.
In my experience the MySQL query cache + an object cache do more for sites with a Recent Comments widget than whole page caching.
As it happens, I do all of the above. And I was doing all of the above. And still getting jammed on I/O. Because MySQL likes to join on disk. Whole page caching is useful only if you prevent that from happening. It's useless if the cache is rendered invalid every few seconds on a chatty site.
set beresp.ttl = 30s;
There's also the possibility that you had shitty neighbors.
Right, and when I hosted on WPEngine and then on Pagely (and both of them choked), my users immediately piped up that the recent comments were inaccurate. In fact there were a number of page freshness anomalies which I believe were down to whole-page caching that I was frequently quizzed about by users.
If your page is basically static, then yes, whole-page caching will fly. But several of the sites under my supervision are, to quote Pagely's founder, used "like a chat room".
Edit, per your edit:
> I'm just saying you could have made this work on Linode (and I have), but I do see your post-purchase rationalization at work, so I know anything I say will be fruitless anyway.
Basically, I was there, I saw the numbers and I know why they wound up looking the way they did. I suspect that anyone in my particular situation would have evolved their approach in the same way that I have. I've been running Wordpress blogs since 2004. I feel that I've picked up some ideas on how to make it fast, but sometimes the general solutions don't work because you have a specific problem.
If your page is basically static, then yes, whole-page caching will fly. But several of the sites under my supervision are, to quote Pagely's founder, used "like a chat room".
Edit, per your edit:
> I'm just saying you could have made this work on Linode (and I have), but I do see your post-purchase rationalization at work, so I know anything I say will be fruitless anyway.
Basically, I was there, I saw the numbers and I know why they wound up looking the way they did. I suspect that anyone in my particular situation would have evolved their approach in the same way that I have. I've been running Wordpress blogs since 2004. I feel that I've picked up some ideas on how to make it fast, but sometimes the general solutions don't work because you have a specific problem.
Got it. So you have users that expect to have real-time conversations in the comments on a blog, meaning you can't optimize a blog application like a blog is designed to be used, meaning you have to pay for SSDs in order to make your blog function at all because apparently MySQL can't handle N inserts/second and however many people have these conversations refreshing every ten seconds, generating a few SELECTs that are rapidly in query cache.
I completely understand how this could be a problem and how switching providers would fix it.
I completely understand how this could be a problem and how switching providers would fix it.
Sarcasm aside, you clearly don't understand what my problem is.
1. Recent Comments invalidates every page it appears on whenever a comment is posted in any thread. In practice that means that the entire site cache is invalid. That breaks whole-page caching models.
2. This means that Wordpress will regenerate from scratch.
3. This means first of all generating the page, which joins multiple tables including TEXT fields. Because of the brilliant design of MySQL, these joins ignore indices on the joining fields and frequently the join will occur on disk.
4. The Recent Comments plugin also causes joins on disk because it too refers to tables with TEXT fields.
5. The query cache helps a lot, but the site on Linode was still observably jammed on I/O, even when MySQL was given an entire server to itself.
However, if you feel you can do it better, I am happy to engage your services as a fulltime replacement. WPEngine said they could do it for $250/month (they couldn't). Pagely said they could do it for $149/month (they couldn't). I invite your bid.
1. Recent Comments invalidates every page it appears on whenever a comment is posted in any thread. In practice that means that the entire site cache is invalid. That breaks whole-page caching models.
2. This means that Wordpress will regenerate from scratch.
3. This means first of all generating the page, which joins multiple tables including TEXT fields. Because of the brilliant design of MySQL, these joins ignore indices on the joining fields and frequently the join will occur on disk.
4. The Recent Comments plugin also causes joins on disk because it too refers to tables with TEXT fields.
5. The query cache helps a lot, but the site on Linode was still observably jammed on I/O, even when MySQL was given an entire server to itself.
However, if you feel you can do it better, I am happy to engage your services as a fulltime replacement. WPEngine said they could do it for $250/month (they couldn't). Pagely said they could do it for $149/month (they couldn't). I invite your bid.
> Sarcasm aside, you clearly don't understand what my problem is.
Yeah, I spent this entire thread clueless about the issue you're running into, even though you spelled it out a few different times because you think I don't get it. Wordpress falls over under normal site load, film at eleven.
Since you want to switch to condescension, I'm assuming wise sir moved MySQL's tmpdir to a RAM disk and found that unsatisfactory for his mystical, MySQL-breaking SELECT/INSERT workload? Also, I'm far more expensive, and I know that WPEngine is multitenancy Wordpress on Linode in the backend. (That one's free.)
Yeah, I spent this entire thread clueless about the issue you're running into, even though you spelled it out a few different times because you think I don't get it. Wordpress falls over under normal site load, film at eleven.
Since you want to switch to condescension, I'm assuming wise sir moved MySQL's tmpdir to a RAM disk and found that unsatisfactory for his mystical, MySQL-breaking SELECT/INSERT workload? Also, I'm far more expensive, and I know that WPEngine is multitenancy Wordpress on Linode in the backend. (That one's free.)
that popular posts widget sucks :D
Hey fellow Australianite.
I've been looking at using DO instead of Amazon, the main stumbling block for me is I cannot seem to figure out if they offer any configurable firewal. Ie I want to modify port rules, blocking them mostly.
Does DO offer this, and how have you found them so far?
My use case is similar to yours - hosting for multiple shopping carts running on MySQL, hence the appeal of SSDs.
I've been looking at using DO instead of Amazon, the main stumbling block for me is I cannot seem to figure out if they offer any configurable firewal. Ie I want to modify port rules, blocking them mostly.
Does DO offer this, and how have you found them so far?
My use case is similar to yours - hosting for multiple shopping carts running on MySQL, hence the appeal of SSDs.
Another Australianite here.
You can just bind to localhost if you don't want things to be open to the world, or modify iptables.
Your other issue in Australia is the latency to DO's servers - ~200ms for the US and 350+ for a European droplet. Cloudflare may help there, though.
You can just bind to localhost if you don't want things to be open to the world, or modify iptables.
Your other issue in Australia is the latency to DO's servers - ~200ms for the US and 350+ for a European droplet. Cloudflare may help there, though.
It's a blog network. Latency matters, but not so much that I can justify paying the ruinous bandwidth rates Australian hosts want. I'd be looking at several hundred extra dollars per month for what is really a quite modest operation.
> Your other issue in Australia is the latency to DO's servers
Roughly 160ms from East Coast AU to DO's LA droplets, most of us are used to the extra milliseconds by now :-)
Roughly 160ms from East Coast AU to DO's LA droplets, most of us are used to the extra milliseconds by now :-)
I don't think DigitalOcean themselves offer a firewall. You'd need to block ports at your server.
They don't :(
Sounds over-engineered, slower and possibly over-priced.
A consumer SSD will be faster and so long as it is trimmed correctly and not fully utilized, it should be sufficiently reliable.
For people that require a large bulk of data but who also leave most of it cold, unused, front-caching SSDs are brilliant. Paying four times as much for twice the performance and far better reliability is a no-brainer for this- what's the opposite of a bottleneck- accelerator? Data reserve+pump?
What would you guess is the average interval between accesses for any given byte-on-disk a Linode customer has? If it's hours, days, or weeks, I'd call it reckless to be spending money to put those bytes on expensive SSD systems.
Make the hot stuff fast, be price conscious with the rest.
What would you guess is the average interval between accesses for any given byte-on-disk a Linode customer has? If it's hours, days, or weeks, I'd call it reckless to be spending money to put those bytes on expensive SSD systems.
Make the hot stuff fast, be price conscious with the rest.
It's a free upgrade coming to everyone eventually.
But your not the only person using the SSD, you can't trust that every VM, will A) Discard or B) use the SSD in a sane way.
while its a welcome move, it should have been done some time ago.
Also worth mentioning that for 59€/mo Hetzner is offering a dedicated i7-4770 Haswell with 32GB RAM and dual SSD raid1.
http://www.hetzner.de/en/hosting/produkte_rootserver/ex40ssd
http://www.hetzner.de/en/hosting/produkte_rootserver/ex40ssd
NB: +99€ for setup.
How is everyone satisfied with hetzner? I have a few friends that run setups on their systems, mostly for heavy forums. I'm more interested how do you deal with large backups? Seems to me it's just easier to buy machines in sets for redundancy and every now and then move things over to glacier.
How is everyone satisfied with hetzner? I have a few friends that run setups on their systems, mostly for heavy forums. I'm more interested how do you deal with large backups? Seems to me it's just easier to buy machines in sets for redundancy and every now and then move things over to glacier.
If you're OK with the latency to Europe from where you are, Hetzner is great.
I used them quite a bit (and still do), however even with Cloudflare my tests were a bit sluggish here in Perth,AU.
I used them quite a bit (and still do), however even with Cloudflare my tests were a bit sluggish here in Perth,AU.
Lindo SSDs are expensive, and the good SSDs are really, really expensive. Although the cheaper SSDs exist, they wear out more quickly, potentially slowing down as they wear, and have slower overall throughput. Not a good combination for use in multi-tenant server workloads.
> Random IO is processed first through the SSDs (the thing that they are really good at) while sequential IO short-cuts to the hard drives - which is pretty slick.
Any idea why the sequential benchmark numbers improved 4-5x when it is still "short-cutting" to the HDs?
Any idea why the sequential benchmark numbers improved 4-5x when it is still "short-cutting" to the HDs?
Possibly because the HDDs are free to only do long sequential reads, as opposed to having to seek to some random place every now and then.
Linode has "developed" nothing. Linode is using bcache as a tiered storage but there are problems such as certain IO patterns will bypass bcache and hammer the disks causing slower-than-disk-alone IO speed.
From the description it sounds like they're just using bcache for the storage layer, or one its equivalents (IIRC Facebook came out with a very similar patch). Still pretty cool
So SSDs are bad for server loads... what secret sauce does Digital Ocean have that Linode doesn't? Did they write their own storage layer that's doing something cool?
http://arstechnica.com/information-technology/2013/07/linux-...