Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Do you think this IO is problematic, what would you do?
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.

Do you think this IO is problematic, what would you do?

I have an LET host (who I won't name b/c I don't want to use LET as a bashing platform).

But, I am a bit concerned with some of its IO performance. Part of my deployment method is to upload static files into a "staging" folder, and then "cp -r" the complete staging folder into a folder on the live server. The idea is that all files get switched live at once (more or less) to prevent users from seeing some old and some new files, which could occur if I were to upload the static files directly into the live folder (as uploading files is somewhat slow from my office).

The problem is that the "cp -r" command takes forever about 8-22 minutes to copy 1.16 GB total (broken up into about 8 folders and a total of 500 files). Openvz 1GB ram.

Typically the server runs with almost no load. I have had no problems otherwise with the server. And there is not many active users on the web app (though that will likely change over the next month).

My concern is that there is an underlying IO problem that will cuase lots of problems once users start using the server more. Does my concern sound valid? Is the performance times for "cp -r" pretty slow in your opinion?

Comments

  • Do a disk speed test?

  • @Ishaq said:
    Do a disk speed test?

    I ran dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync

    output:

    1073741824 bytes (1.1 GB) copied, 34.0852 s, 31.5 MB/s

  • SpartanHostSpartanHost Member, Host Rep

    @AdamM said:

    @Ishaq said:
    Do a disk speed test?

    I ran dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync

    output:

    1073741824 bytes (1.1 GB) copied, 34.0852 s, 31.5 MB/s

    That's quite low, might be worth contacting the provider to see if that's what you should expect.

    Thanked by 1AdamM
  • Ran it again and got:

    1073741824 bytes (1.1 GB) copied, 63.77 s, 16.8 MB/s

  • Yeah, even for HDD it's a bit low.

    Depends on their array setup and what kind of I/O wait/load there is.

  • A few points:

    1. Independent of the IO speed of the VPS, do try to use rsync - it will help a lot in terms of avoiding "work" if there are no changes to files. This is probably more useful to upload files from your office to the VPS. Nevertheless it should help with the completely local folder-to-folder copy.

    2. The IO speeds are definitely low/poor (as confirmed by the others as well). One caveat to watch out for is that the typical dd benchmark tests write speeds which many times will be decent despite the read speeds (of a lot of files in many folders) being pretty bad. This is again due to high IO/Memory/Cache pressure on the host (and in my experience is a good indicator of overselling or underpowered node/resources for the kind of work load the node is supporting). So just because dd works well it does NOT imply that all is well.

    HTH.

    Thanked by 1AdamM
  • @nullnothere said:
    A few points:

    1. Independent of the IO speed of the VPS, do try to use rsync - it will help a lot in terms of avoiding "work" if there are no changes to files. This is probably more useful to upload files from your office to the VPS. Nevertheless it should help with the completely local folder-to-folder copy.

    Yes, my new work flow only pushes the changes (not using rsync), but somewhat similar.

    I am not so much concerned with the long wait time for folder-to-folder copy (I can sip some coffee while that happens), I am more concerned that this might mean there is an underlying IO problem with the VPS, that will be problematic once the vps get higher usage in the next month.

  • vapornodevapornode Member
    edited November 2016

    If the IO does remain abysmally slow, your users will notice a delay when usage picks up. This doesn't usually indicate a problem with your VPS but with the host node itself.

    Thanked by 1AdamM
  • Open a ticket and tell the host you find that performance to be abysmal and unacceptable.

    If it doesn't improve then you probably bought oversold shit services. Let me guess, $20/yr for 400GB storage ?

    Thanked by 1AdamM
  • MaouniqueMaounique Host Rep, Veteran
    edited November 2016

    JoeMerit said: Let me guess, $20/yr for 400GB storage ?

    Storage node is storage node, we have xen large nodes with enterprise sata disks in raid 6 which clock about 150 MB/s in best days. We don't stop anyone from using them for other purposes, but you should not expect SSD-like performance on a storage node.
    31 MB/s is decent still for storage and backup, it is unlikely many transfers will pass that, however, what should worry you is the halving of that in the next test, it should be more or less consistent.

  • How about using mv -f instead of cp so it doesn't actually copy the data?

  • @DBA said:
    How about using mv -f instead of cp so it doesn't actually copy the data?

    Yes that would work, but (as I was trying to explain above), my concern is not actually about how long it takes to "cp -r" but if the long time to do so is indicative of an underlying IO problem with the host node.

  • What is the disk IO like during off peak hours?

  • @Samistine said:
    What is the disk IO like during off peak hours?

    What test would you recommend running to test disk IO (one that is not disruptive to the host)?

  • HarambeHarambe Member, Host Rep

    @AdamM said:

    Your concern sounds valid. I'd ticket if you haven't already.

    For curiosity sake, run df -h and check that the 'available' storage matches up to what your plan offers and what you've used. If it's less than what your plan has then the box is overloaded and running out of disk space.

    Also take a look at the first 'filesystem' line and see if it's /dev/simfs or /dev/ploop*. If you have garbage I/O and they're using ploop then the box is running out of ram and swapping.

    Just a couple things I've seen with some bad OVZ hosts. Also, feel free to name the host here and hopefully they can get it fixed.

  • Harambe said: For curiosity sake, run df -h and check that the 'available' storage matches up to what your plan offers and what you've used.

    I ran this, and df -h checked out fine.

    @Harambe said:

    Also, feel free to name the host here and hopefully they can get it fixed.

    I submitted a ticket last Thursday, they say they are looking into it. I want to give them the opportunity to figure it out.

  • I recommend you find another host. that is such a slow performance. i think host is overselling much to the point that performance is affected.

  • JoeMeritJoeMerit Veteran
    edited November 2016

    how about you tell us how much you are paying for this 1GB ovz ? depending on what you are paying, that shit i/o might be reasonable. i.e, the super premium $10 per year plan.

  • AnthonySmithAnthonySmith Member, Patron Provider

    How about this for a suggestion, if it does get slower to the point it actually affects you, change hosts.

    Thanked by 1jcaleb
  • JoeMerit said: how about you tell us how much you are paying for this 1GB ovz ? depending on what you are paying, that shit i/o might be reasonable. i.e, the super premium $10 per year plan.

    $23 a year 1 GB ovz, 150 GB HDD, 2 TB transfer

    jcaleb said: I recommend you find another host. that is such a slow performance.

    I am giving them to the end of the day to address the issue

  • AnthonySmithAnthonySmith Member, Patron Provider

    AdamM said: 1 GB ovz, 150 GB HDD, 2 TB transfer

    Sounds like a good deal, especially if the IO is not actually affecting you, same price as 6 packets of flaming hot doritos :)

    For that much disk space at a similar price you could consider Ramnode or INIZ, but my guess would be its one of those already, and Ramnode is shit hot on IO.

  • AnthonySmith said: Sounds like a good deal,

    It is a good deal, I think I am getting a good value, I just wanted to see what people thought about the IO speed...

  • AdamM said: It is a good deal, I think I am getting a good value, I just wanted to see what people thought about the IO speed...

    It's not about us, it's about you. Are you happy with the host? Even if io is 1mbps, if you are happy for whatever reason, then stay with them.

  • @jcaleb said:
    It's not about us, it's about you. Are you happy with the host? Even if io is 1mbps, if you are happy for whatever reason, then stay with them.

    Yes you are correct, it is not about what LET thinks is good. But, it is nice to bounce ideas of some of the resident experts here. I don't have too much experience about what happens when IO is slow on a host when usage increases.

  • It is slow as a water buffalo

  • @AdamM said:

    @jcaleb said:
    It's not about us, it's about you. Are you happy with the host? Even if io is 1mbps, if you are happy for whatever reason, then stay with them.

    Yes you are correct, it is not about what LET thinks is good. But, it is nice to bounce ideas of some of the resident experts here. I don't have too much experience about what happens when IO is slow on a host when usage increases.

    How did you find out the IO was slow?

  • Nekki said: How did you find out the IO was slow?

    I occasionally run a "cp -r" for a folder-to-folder copy of about 1.3 GB total broken up into about 500 files. The "cp -r" takes about 8-22 seconds. Seemed a bit off to me. However, the vps (otherwise) runs fine: but the vps is not under high usage now (but will be in about a month).

  • You said: 8-22 minutes

  • @jcaleb said:
    You said: 8-22 minutes

    yes that is correct

  • AdamM said: The "cp -r" takes about 8-22 seconds.

    AdamM said: The problem is that the "cp -r" command takes forever about 8-22 minutes

Sign In or Register to comment.