3 ms·

I'm done with slow disk on cloud hosts. But actually the one with slow disk was Slicehost, and I AM fed up to hell with that. They caused me no end of problems

I'm done with slow disk on cloud hosts. But actually the one with slow disk was Slicehost, and I AM fed up to hell with that. They caused me no end of problems until I figured out they were the problem. It's a bit deceptive, really, since you're promised your fair share of resources - then it turns out you're disk i/o is as low as 3/mb a sec. W T F. Instead of going nuts and hosting in my garage, though... I just changed hosts. A rack on a colo would make more sense than the garage route, too.

lsc 16y ago
3MB/sec isn't a fair share of a disk? I think it is. to start, your cheap sata disk is going to max out a 100Mb/sec for /sequential/ transfers. Now, cut that in quarters, because two different guests streaming data to the disk make sequential random. so you have 25MB/s. double it, as they are probably raid-10ing the disk (at least, that's what I do) so we have a best case 50MB/s to share. Now, they are probably in a box with 32GiB ram. say they give a gig to the dom0, and you are on a 512MiB guest. that means you are sharing with 62 total guests. So your fair share is less than 1MB/sec of hard drive transfer. Of course, best case, nobody else is using the drive and you get all 200MB/s, but with 60 guests, that won't happen often. Hard drives suck. Sharing hard drives makes them suck a lot more. Note, I know almost nothing about the actual slicehost setup; what I'm describing here is guesses about their setup based on what I know about xen and what I know of my own set up. My understanding is that Linode is perceived by light users to have better I/O throughput, but this is because they monitor and take action against heavy I/O users. (I think this is a good idea, and may implement it myself)
- code_duck 16y ago
  Your calculations assume I am talking about bog $20/mo VPS. Nope, I'm talking about a $160 a month system with 2GB ram, 72 MB HD space, etc. As far as I know 4-8 of those fit on one of their systems. If I had a 256/384 slice, yeah, I doubt if the rest of the system could handle enough traffic that the I/O would matter. My 2 year old, nothing special home desktop gives me 72 mb/s. I expect that a pricey VPS will perform at least as well. If not, I could get a dedicated server for $40 more. Running hdparm, slicehost gave me 3-48 mb/s. When it was down under 20, my server was choking doing the simplest tasks - like say, logging into ssh while actually serving HTTP requests. Performance was sucking. Customers complained. I tried tuning my DB. Nope, it wasn't my fault. System load ranged from 3-50 for no apparent reason. The same test on Linode yields 98-165 mb/s. I moved the server to Linode (saving $80 a month!!), have added new features and increased usage, and performance remains excellent. No mysterious slowdowns, no high system load. Everything hums along without a hitch, proving to me it is Slicehost's problem, not mine. Thank god it is theirs to deal with now. This caused me a lot of stress and I'm so glad to be on a host that is giving me what I am paying for. I'm sure you know more about this from that side, but this is my experience as user. 3mb/sec is unusable for a moderately busy server. The fact that other hosts give better performance says all I need to know. If they gave a steady 30-40 mb/s, from your calculations, that's what I'm paying for and yeah, that's probably all I need. The unsteadiness, though, and the dips to near nothing - that is unacceptable. I'm not a hobbyist. This is a business, other businesses depend on us.
  - lsc 16y ago
    Yeah, like I said, I from what I hear, linode is managing disk I/O well. Have you ever gotten a warning about using too much IO from linode? ok, so let's go back and see the math again... so there were 14 systems or so on that 32GiB system, so if everyone was going at the disk, you'd get what, 3.5MB/sec- about what you were seeing. I'm just pointing out, when you 'virtualize' a hard drive, you are sharing a resource that really doesn't share very well. you were getting your 'fair share' of the server at slicehost; it sounds like linode just does a much better job of keeping everyone from trying to use all available disk at all times.
    - code_duck 16y ago
      Our i/o isn't really very high. It is under 1 mb/s on average, actually! So I have no idea what the issue is. You're right, 3 MB/S SHOULD be enough because according to our Linode graph, the i/o hasn't been over 2 mb/s in the past week. I can only imagine that certain times at Slicehost must have been providing less than at the times I tested it. That's what is frustrating for me. We don't have a demanding application. It's well written and tuned, but I was having these problems, and as far as I knew I was paying enough to not have such problems. Maybe we're on a spacious server at Linode or were graced with idle neighbors... all I know is, the system load on Linode is muuuch more stable, (and low!) even though our system is doing twice as much. And, it costs half as much.
      - lsc 16y ago
        I didn't say 3MB/sec was enough... just that it was fair. there's a difference, you know. I suspect the differences you saw after moving had to do with how active the other users of the disk were. this may have been chance, or it may have been Linode's policy of pro actively doing things about heavy disk users.
        code_duck 16y ago
        Thanks for your insights on this.

lsc 16y ago

3MB/sec isn't a fair share of a disk? I think it is. to start, your cheap sata disk is going to max out a 100Mb/sec for /sequential/ transfers. Now, cut that in quarters, because two different guests streaming data to the disk make sequential random. so you have 25MB/s. double it, as they are probably raid-10ing the disk (at least, that's what I do) so we have a best case 50MB/s to share. Now, they are probably in a box with 32GiB ram. say they give a gig to the dom0, and you are on a 512MiB guest. that means you are sharing with 62 total guests. So your fair share is less than 1MB/sec of hard drive transfer. Of course, best case, nobody else is using the drive and you get all 200MB/s, but with 60 guests, that won't happen often. Hard drives suck. Sharing hard drives makes them suck a lot more. Note, I know almost nothing about the actual slicehost setup; what I'm describing here is guesses about their setup based on what I know about xen and what I know of my own set up. My understanding is that Linode is perceived by light users to have better I/O throughput, but this is because they monitor and take action against heavy I/O users. (I think this is a good idea, and may implement it myself)

code_duck 16y ago
Your calculations assume I am talking about bog $20/mo VPS. Nope, I'm talking about a $160 a month system with 2GB ram, 72 MB HD space, etc. As far as I know 4-8 of those fit on one of their systems. If I had a 256/384 slice, yeah, I doubt if the rest of the system could handle enough traffic that the I/O would matter. My 2 year old, nothing special home desktop gives me 72 mb/s. I expect that a pricey VPS will perform at least as well. If not, I could get a dedicated server for $40 more. Running hdparm, slicehost gave me 3-48 mb/s. When it was down under 20, my server was choking doing the simplest tasks - like say, logging into ssh while actually serving HTTP requests. Performance was sucking. Customers complained. I tried tuning my DB. Nope, it wasn't my fault. System load ranged from 3-50 for no apparent reason. The same test on Linode yields 98-165 mb/s. I moved the server to Linode (saving $80 a month!!), have added new features and increased usage, and performance remains excellent. No mysterious slowdowns, no high system load. Everything hums along without a hitch, proving to me it is Slicehost's problem, not mine. Thank god it is theirs to deal with now. This caused me a lot of stress and I'm so glad to be on a host that is giving me what I am paying for. I'm sure you know more about this from that side, but this is my experience as user. 3mb/sec is unusable for a moderately busy server. The fact that other hosts give better performance says all I need to know. If they gave a steady 30-40 mb/s, from your calculations, that's what I'm paying for and yeah, that's probably all I need. The unsteadiness, though, and the dips to near nothing - that is unacceptable. I'm not a hobbyist. This is a business, other businesses depend on us.
- lsc 16y ago
  Yeah, like I said, I from what I hear, linode is managing disk I/O well. Have you ever gotten a warning about using too much IO from linode? ok, so let's go back and see the math again... so there were 14 systems or so on that 32GiB system, so if everyone was going at the disk, you'd get what, 3.5MB/sec- about what you were seeing. I'm just pointing out, when you 'virtualize' a hard drive, you are sharing a resource that really doesn't share very well. you were getting your 'fair share' of the server at slicehost; it sounds like linode just does a much better job of keeping everyone from trying to use all available disk at all times.
  - code_duck 16y ago
    Our i/o isn't really very high. It is under 1 mb/s on average, actually! So I have no idea what the issue is. You're right, 3 MB/S SHOULD be enough because according to our Linode graph, the i/o hasn't been over 2 mb/s in the past week. I can only imagine that certain times at Slicehost must have been providing less than at the times I tested it. That's what is frustrating for me. We don't have a demanding application. It's well written and tuned, but I was having these problems, and as far as I knew I was paying enough to not have such problems. Maybe we're on a spacious server at Linode or were graced with idle neighbors... all I know is, the system load on Linode is muuuch more stable, (and low!) even though our system is doing twice as much. And, it costs half as much.
    - lsc 16y ago
      I didn't say 3MB/sec was enough... just that it was fair. there's a difference, you know. I suspect the differences you saw after moving had to do with how active the other users of the disk were. this may have been chance, or it may have been Linode's policy of pro actively doing things about heavy disk users.
      - code_duck 16y ago
        Thanks for your insights on this.