amuck-landowner

DD Script

SkylarM

Well-Known Member
Verified Provider
I think I proved an issue with my provider when they where getting nearly constant I/O speed of less then 20MB/s.


Mun
If you have to "prove" an issue to your provider before they will look into a disk performance issue, then you likely need a new provider*.

* I mean stop giving GVH money.

Releasing an easy to access script that chain runs DD results (regardless if on a timer or not) will likely result in an increase in abuse. There are people out there too lazy/not familiar with this sort of thing that would gladly attempt to raise hell with a provider if a script is easily accessible that does all the work for them. Keep that in mind.
 
Last edited by a moderator:

tchen

New Member
One other thing, if despite all recommendation to not release this you still decide to do so, then at the very least embed some randomize delay into the script.  The last thing anyone needs is a bunch of people running this script on a node on the hour, at exactly the same time.
 

DomainBop

Dormant VPSB Pathogen
I thought I saw runs every 2 hours.
Every 2 hours is bad! If you run the script during even hours and the abusers only abuse during odd hours you'll never know that the node you're on has dd speeds below 10 Mbps half the day! Solution: run it every hour!
 

kaniini

Beware the bunny-rabbit!
Verified Provider
IOWAIT is good to determine if your process(es) are/is being held up by your disk / latency, but it isn't a good determiner if that IOWAIT is because of how the program is written, or if it is because the disk is getting hammered.

Mun
If you have a proper VM, i.e. not OpenVZ, you can measure request latency times to determine this.
 

raindog308

vpsBoard Premium Member
Moderator
This

Is

The

Stupidest

Thing

In

The

World
I think it's worse than that, actually.

It's also lame.

I mean, what is this other than dd if=/something of=/something bs=something >> data.txt ?  "built a bash + crontab script" ?  Really?  It's not like you're even parsing the data and putting it in MySQL, producing graphs, etc.  What exactly is there to "release" -?  One line of "code"?

Besides the other suggestions, ioping is another useful thing.
 
This is one of the most useless 'scripts' I have ever seen in my 20 years of being around the IT field. 

ioping is equally useless on Linux because of the shared page (vsyscall) between userland and the kernel, which will not give you accurate results. Not only that, context switching is expensive on x86, Only way to measure raw access time is to do it within the kernel, not userland.
 

DomainBop

Dormant VPSB Pathogen
ioping is equally useless on Linux because of the shared page (vsyscall) between userland and the kernel, which will not give you accurate results.
Agreed about ioping tests, and if we want to take it a step farther, choosing a VPS provider based primarily on the "blazing fast" dd and ioping results the provider posted in their offer is equally pointless.
 

tchen

New Member
Agreed about ioping tests, and if we want to take it a step farther, choosing a VPS provider based primarily on the "blazing fast" dd and ioping results the provider posted in their offer is equally pointless.
Call me a noob here.  So the timing functions used ioping goes through vsyscall (I assume gettimeofday) on both ends of the heavier aio/block io calls.  Sure, the file system calls get hit with the context switch, but where does the inaccuracy come in?  Are we saying that it doesn't measure the raw disk spindle, which I thought was a given as the test was designed as a kernel-userland interface test?  Or did I misunderstand and there's something more fundamental elsewhere?  I'm curious.
 
Call me a noob here.  So the timing functions used ioping goes through vsyscall (I assume gettimeofday) on both ends of the heavier aio/block io calls.  Sure, the file system calls get hit with the context switch, but where does the inaccuracy come in?  Are we saying that it doesn't measure the raw disk spindle, which I thought was a given as the test was designed as a kernel-userland interface test?  Or did I misunderstand and there's something more fundamental elsewhere?  I'm curious.
Where does the inaccuracy come from? 

- Gettimeofday, on Linux, is setup with a shared page designed to cache/not perform a full read from hardware (depending on how good your timesources are), which makes it less expensive to call. It's not going to be completely accurate this way, either. Speed != Accuracy. That is why other OS's like FreeBSD have slower gettimeofday()/clock_gettime() because they perform a full lookup directly from the hardware. Mac has commpage, which is similar. This is a pessimistic issue, though (you're talking about ~50uS maybe on VPS's and modern CPUs)

- VPS's do not give direct access to hardware. You need ring0 to access say, the PIT/ACPI, but you don't need either to call rdtsc(). Some/most instructions are emulated, 

- VPS's when they call write() do some funky caching stuff because, again, they do not have direct access to hardware. 

ioping is only useful on dedicated servers, not VPS containers. You'll see wild results and they won't be consistent. 
 

tchen

New Member
ioping is only useful on dedicated servers, not VPS containers. You'll see wild results and they won't be consistent. 
Thanks for the instruction above.  I do see ioping results fluctuate wildly on VPS but I had always chalked that up to general noise from interleaved access by neighbours.  I guess it wasn't just that.

When put through a time series though, it does have a relatively stable mean distribution.  Enough to work with - as long as you're not that guy on LET who cherry picks the lowest value to start a "It's a fraud" thread :p
 

raindog308

vpsBoard Premium Member
Moderator
ioping is only useful on dedicated servers, not VPS containers. You'll see wild results and they won't be consistent. 
Interesting...though I've see good ioping times from good hosts and bad ioping times from bad hosts (where good/bad means "non/oversubscribed IO").

I never was much for benchmarks in the absolute sense, though.  If I'm solving a problem, having a before/after change benchmark is invaluable, but to just get on a host and run some benchmark.sh...pointless.
 
Last edited by a moderator:

drmike

100% Tier-1 Gogent
Big question is there much useful that can be ran from within a container to deduce performance baseline whatsoever?

The disk lust in the low end is notorious.

I'd ran the pedestrian things aforementioned and still do... usually when I see laggy or just off nodes...

Time for some of us (not me) to fashion better metrics for container analysis.
 
Top
amuck-landowner