I'm a little confused as to the actual problem being solved here.
For SSDs there is essentially no seek penalty, so random read and sequential read performance are essentially the same. Spinning hard drives, because of the seek penalty, have pretty poor random read performance but fairly good sequential read.
Surely, for a streaming application, it should be sequential read that is the key requirement?
You can predict with a very high degree of accuracy what piece of data you'll be requiring in the near future, at which point the seek can be scheduled well in advance.
This, of course, assumes your data is laid out in a sane fashion and you're not blindly jumping all over the disks.
Strikes me that last.fm could potentially do with looking at approaches like Facebook's Haystack where they put considerable time in to minimising the amount of IOPS required to pull an image off of the disk.
Last.fm does progressive streaming, not HTTP downloads.
i.e. it reads 16KB of one track, sends it to one user, then 16KB of the next track, sends it to the next user, etc. Then after 1 second it goes through and does the whole thing again.
But you've got the additional bonus problem that users can skip Last.fm tracks at any time, so there's a pretty high probability that you won't need all that data anyway.
(I used to work for Last.fm and we spent a fair amount of time working on this issue without a great amount of success.)
I'm also wondering what moved them towards the SLC-based Intel drives as opposed to the MLC-based ones (that offer a much lower price-capacity), since in terms of read performance IOPS they're almost identical.
We were going to go for the larger sized (space wise) MLC based ones except that they're in the smaller form factor, not easy to fit in the server chassis. The connector on them is also non standard, unlike the MLC models which slide right in. Makes a big difference when you're buying a lot of them.
Also, if we ever decide to re-commission these machines later, the SLC based ones will be more useful for us.
I've been using both the MLC and SLC Intels and they both have the same standard SATA connector. Also, server chassis are moving to 2.5" SATA bays, our latest servers have 2 dual processor motherboards in 1U (Supermicro calls them 1U-twin), with 4 2.5" bays for each motherboard.
The chassis has 2.5" bays, and so do the SSDs we used. However, the only MLC SSDs available were 1.8" versions, hence my comment. We had to work pretty hard to get any of them!
Only when implemented naively. Why not transfer the whole 5-10MB file at once into a buffer somewhere (on-box, in a proxy, whatever) and then stream from there? DRAM is vastly cheaper than trying to get a seek-heavy architecture to scale on seek-limited devices.
But then, moving to flash is sort of a complicated version of the same solution...
It's not a complicated version of the same solution - it's cheaper version of the same solution. As expensive as flash is, it's still cheaper than the equivalent amount of RAM.
You wouldn't necessarily need a RAM buffer of the same size as source storage; it depends a lot on what X% of all song-seconds will be played in the next N buffered minutes.
If X is 100%, the approaches converge... but I think lots of things (popularity of songs, discretion over next song played, choice of N, etc.) could make buffers much smaller than total catalog size helpful in seek-reduction.
(The buffer could also be read-write SSD instead of RAM. Or perhaps just for the most popular items or skip-prone early ranges of files.)
These SSD streamers only hold the most popular 10-20% of Last.fm's content, so they are effectively just holding the bytes which are most likely to be streamed.
Cheaper to buy as a part, not cheaper to implement. Given that last.fm has a bunch of boxes with the data already on them, replacing them all with SSD versions sounds like a more expensive solution than a bunch of buffering proxies to me.
And in any case, I said "complicated", not "cheaper", and I'll stand by that. Complexity has costs all by itself.
Run-of-the-mill caching proxies are no good in front of a distributed progressive streaming system such as this, because they would have to be modified to stream progressively and also to authenticate requests, which would increase the complexity far more than the comparatively minor changes Last.fm had to make to MogileFS.
Huh? I'm all but certain that a default squid install would work fine. "Progressive streaming" at the server side generally doesn't require any configuration at all in TCP -- the client reads what it wants, the buffers fill up, and the transmission stalls on a missing ACK. And the authentication layer is almost certainly downstream of the backend storage anyway, so I'm not sure how that would matter.
Swapping hardware is a really expensive expensive change in the IT world, significantly more so than deploying new hardware on an existing infrastructure. That you somehow think otherwise is surprising to me.
Moreover, in order to build out to 320, 640, or 1280 GB with SSD you need only off the shelf technologies (SATA/SAS raid), it's not even that expensive (even a 1TB top of the line SSD array in RAID 10 would cost less than $50k). To match that amount of storage in RAM would require multiple machines, rare motherboards or other hardware, and a huge outlay for RAM. Not to mention it would require pretty significant rewrites of their applications in order to use the RAM properly.
The new server can stream 30,000 concurrent connections. Imagine buffering 30,000 files, each 5-10 MB. That's 150-300 GB ram. I expect a server with SSD is cheaper than one with 300 GB ram, and you don't even have to manage a RAM cache.
Even with that explanation, and the risk of user-triggered track-skips, the seek-heaviness doesn't seem inherent to the problem.
Much of the time, and oftentimes for runs of many minutes/megabytes at a time, you can predict exactly what data will be needed at what future time.
Perhaps another approach would be to add more buffering in front of spinning disks -- perhaps RAM, perhaps SSD -- and tune the disk IO scheduler to be extreme in the other direction: have the app request everything at least N minutes in advance, and let the scheduler take up to N minutes to deliver it. Then it can take advantage of any seek-minimizing physically-near blocks over a much larger window of time.
(For those occasional skip exceptions, data could be pulled from a smaller lower-latency system, or from a smaller set of 'whatever happens to be ready' fill-ins, etc.)
SSDs still have substantially higher sequential read speeds. The specific one they are using (the Intel X-25E) has over two or three times the sequential read speed of 2 of the fastest standard drives.
23 comments
[ 7.0 ms ] story [ 77.8 ms ] threadFor SSDs there is essentially no seek penalty, so random read and sequential read performance are essentially the same. Spinning hard drives, because of the seek penalty, have pretty poor random read performance but fairly good sequential read.
Surely, for a streaming application, it should be sequential read that is the key requirement?
You can predict with a very high degree of accuracy what piece of data you'll be requiring in the near future, at which point the seek can be scheduled well in advance.
This, of course, assumes your data is laid out in a sane fashion and you're not blindly jumping all over the disks.
Strikes me that last.fm could potentially do with looking at approaches like Facebook's Haystack where they put considerable time in to minimising the amount of IOPS required to pull an image off of the disk.
i.e. it reads 16KB of one track, sends it to one user, then 16KB of the next track, sends it to the next user, etc. Then after 1 second it goes through and does the whole thing again.
This is a massively seek-heavy operation.
Even with knowledge of the accesses required in 1s time, you're still bounded by the speed of the movements of the heads.
That said. I wonder if there's any trickery you can do with pre-generating the interleaved data for a group of users.
As in:
1) Read the next 5 (or any amount really) tracks for each of the users in a group.
2) Interleave the 16KB blocks in the same pattern you'd be streaming.
Step 1 is just a whole set of sequential reads. Step 2 is one big sequential write. Then your streaming operation is a single sequential read.
Of course, there's a good chance the overhead on doing the above outweighs the gain.
(I used to work for Last.fm and we spent a fair amount of time working on this issue without a great amount of success.)
I'm also wondering what moved them towards the SLC-based Intel drives as opposed to the MLC-based ones (that offer a much lower price-capacity), since in terms of read performance IOPS they're almost identical.
X25-M: 1,200,000 Hours X25-E: 2,000,000 Hours
I'd be willing to replace them more regularly for the added capacity though.
At that price you can buy 3 X25-Ms and still have more space.
The real difference is in write cycles though: the X25-E can do ten times as many as the X25-M.
Also, if we ever decide to re-commission these machines later, the SLC based ones will be more useful for us.
But then, moving to flash is sort of a complicated version of the same solution...
If X is 100%, the approaches converge... but I think lots of things (popularity of songs, discretion over next song played, choice of N, etc.) could make buffers much smaller than total catalog size helpful in seek-reduction.
(The buffer could also be read-write SSD instead of RAM. Or perhaps just for the most popular items or skip-prone early ranges of files.)
And in any case, I said "complicated", not "cheaper", and I'll stand by that. Complexity has costs all by itself.
So I say it's cheaper and less complex.
Swapping hardware is a really expensive expensive change in the IT world, significantly more so than deploying new hardware on an existing infrastructure. That you somehow think otherwise is surprising to me.
Much of the time, and oftentimes for runs of many minutes/megabytes at a time, you can predict exactly what data will be needed at what future time.
Perhaps another approach would be to add more buffering in front of spinning disks -- perhaps RAM, perhaps SSD -- and tune the disk IO scheduler to be extreme in the other direction: have the app request everything at least N minutes in advance, and let the scheduler take up to N minutes to deliver it. Then it can take advantage of any seek-minimizing physically-near blocks over a much larger window of time.
(For those occasional skip exceptions, data could be pulled from a smaller lower-latency system, or from a smaller set of 'whatever happens to be ready' fill-ins, etc.)
http://anandtech.com/storage/showdoc.aspx?i=3631&p=21