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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
When you suspect/blame a client as I/O abuser
raihan0888
Member
I sent email to 4-5 vps provider asking when you blame/suspend as a cause of I/O abusing?
Not a single company directly mention the I/O rate.can you please tell me why?
if i use 10/15 mb I/O alltime is this abuse vps node? 
Comments
MB/sec is rarely the issue, it's IOP/s that is what kills most arrays.
We've seen users slam 500 iop/s and only be doing ~5MB/sec to the disk. Normal SATA drives can only do 100 iop/sec each so that dies well before your throughput.
We really wanted a 2.6.32 kernel so we can properly monitor and rate limit abusers but since that's a complete unstable mess we're going a different route.
Francisco
2.6.32 is a nightmare!
We had high hopes for the newest 55.x kernels but those are dead to me.
Francisco
IOTOP
@Francisco and all, while we are at the subject - does anyone know how's 2.6.32 OVZ lately? Some providers seem to be using it and i haven't heard any horror stories lately.
A few have been OK on older ones but everyone I know using the latest ones (even the latest stable) has had to revert. We rolled 8 nodes with .32 and they all crashed within 48 hours.
IOTOP only gives you an idea of MB/sec spikes, nothing about IOP/sec.
Francisco
@Francisco thanks. I thought if you don't actually assign and use vswap it is mostly stable, but seems i will wait more before i dare using 2.6.32
HAHAHA no. The vswap crashes haven't been an issue in a very long time. The problem is the kernel is packed full of memleaks and other softlocks that they are slowly squashing.
I don't see .32 being production read (read: 100+ day uptimes) until next year.
Till then I know we'll be announcing something fun to help with I/O spikes in the morning :P
Francisco
Could someone explain IOP/s please..
IO operations per second.
Francisco
What sort of stuff causes high iops and low mb/s ?
Reading many small files ? Reading a fragmented database ?
Reading many small files ? Reading a fragmented database ?
tons of small reads/writes all at once. A very large SQL database can do it, or a very poorly designed database without enough indexes can also do it
EDIT - Fixing it to include write as well
Francisco
Sounds interesting @Francisco
Xen wise you can use some per scripts to batch export iops rate per VPS and set your interval, 30 seconds, 60 seconds 5 minutes etc, little bit of awk'ing etc and it is easy enough to get a reliable output.
I am not overly experienced with OpenVZ, I know the default obviously does not create individual LV's but is it possible to go that route? if so it would be easy enough to accurately measure. (obviously you could not then oversell disk)
e.g.
while [[ 1 ]]; do ((lvdisplay|awk '/LV Name/{n=$3} /Block device/{d=$3; sub(".*:","dm-",d); print d,n;}') && (iostat -m)) | sort | uniq | sort | grep '^dm-' | while read hdd; do key=$(echo "$hdd" | egrep -o 'dm-[0-9]+'); if [[ "$key" == "$key2" ]]; then echo "$(date '+%F %T') - $hdd,$hdd2"; fi; hdd2=$hdd; key2=$(echo "$hdd" | egrep -o 'dm-[0-9]+'); done; sleep 30; doneNah.
In .32 you can jimmy rig some code like we do but it's still not 100% accurate due to the I/O scheduler.
Francisco
Shame, you can produce some nice stats to plug in to solusvm/billing portals with that + rrd e.g.
!(http://i.imgur.com/OEMMb.png)
!(http://i.imgur.com/bbbSJ.png)
Easy enough to convert to iops instead of MB or B p/s too
edit: heh.. guess you need to use img tags here
Not really :P
Remember, an iop can be a byte or anything like that. You could be hopeful that it's 64K or something easy like that but yea
Francisco
@Francisco
Sure it is, just with a completely different tool set such as xenstat.pl that actually measures IOPS
Obviously I don't think 1MB = 100 IOPS
Not for OpenVZ though.