I took a few minutes to look at your data.What is the unit of time for Total Time? Seconds?Little's Law shows a consistent 2560 jobs in the system if Total Time is seconds? Did you use 2560 threads of execution?You should replot (log and linear y-axis) the interactions and color code the Test typeiomelt.sa<-read.csv('iomelt-m1.large-sa-east-1',head=T,sep=';')
plot(c(min(iomelt.sa$ts),max(iomelt.sa$ts)),c(min(iomelt.sa$Total.Time),max(iomelt.sa$Total.Time)),type='n',xlab='Time',ylab='Total Time (sec)',log='y')
for(x in 1:nlevels(iomelt.sa$Test)){points(iomelt.sa$ts[iomelt.sa$Test==iomelt.sa$Test[x]],iomelt.sa$Total.Time[iomelt.sa$Test==iomelt.sa$Test[x]],col=as.numeric(x),pch=20,cex=.5)}
legend(locator(),legend=levels(iomelt.sa$Test),col=1:nlevels(iomelt.sa$Test),lwd=3,lty=1)
title("SA").There is some periodicity to the Serial Write data. There an influential hit every 1648 seconds, and less influential every 832 seconds and 660 seconds. 1648 seconds is nearly a harmonic of 832 seconds.ISP frequently over subscribe customers so I would expect some uncontrollable time of day effects due to internet traffic.I used locator to pick the approximate center point of the Serial Read data points. I then used date -r to convert the numerical value to PDT:iomelt robertlane$ date -r 1344754940Sun Aug 12 00:02:20 PDT 2012iomelt robertlane$ date -r 1345101995Thu Aug 16 00:26:35 PDT 2012iomelt robertlane$ date -r 1345370444Sun Aug 19 03:00:44 PDT 2012iomelt robertlane$ date -r 1345529140Mon Aug 20 23:05:40 PDT 2012The do not occur at the same time every day.Before you get lost in the details of the individual trees, you should answer some questions:
- Why are random rewrites faster than serial writes?
- Why are random rereads slower than serial reads?
- Why is there such a large gap in read and write times?
Here is a histogram with overlaid density plot.Some of your plots show multiple modes and striations in the data that do not appear with this data set. You need to be able to explain the differences.Bob
--To view this discussion on the web visit https://groups.google.com/d/msg/guerrilla-capacity-planning/-/D7bZFbSob70J.
You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To post to this group, send email to guerrilla-cap...@googlegroups.com.
To unsubscribe from this group, send email to guerrilla-capacity-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/guerrilla-capacity-planning?hl=en.
Stephen...
To unsubscribe from this group, send email to guerrilla-capacity-planning+unsub...@googlegroups.com.
I took a few minutes to look at your data.What is the unit of time for Total Time? Seconds?Little's Law shows a consistent 2560 jobs in the system if Total Time is seconds? Did you use 2560 threads of execution?
You should replot (log and linear y-axis) the interactions and color code the Test typeiomelt.sa<-read.csv('iomelt-m1.large-sa-east-1',head=T,sep=';')
plot(c(min(iomelt.sa$ts),max(iomelt.sa$ts)),c(min(iomelt.sa$Total.Time),max(iomelt.sa$Total.Time)),type='n',xlab='Time',ylab='Total Time (sec)',log='y')
for(x in 1:nlevels(iomelt.sa$Test)){points(iomelt.sa$ts[iomelt.sa$Test==iomelt.sa$Test[x]],iomelt.sa$Total.Time[iomelt.sa$Test==iomelt.sa$Test[x]],col=as.numeric(x),pch=20,cex=.5)}
legend(locator(),legend=levels(iomelt.sa$Test),col=1:nlevels(iomelt.sa$Test),lwd=3,lty=1)
title("SA").There is some periodicity to the Serial Write data. There an influential hit every 1648 seconds, and less influential every 832 seconds and 660 seconds. 1648 seconds is nearly a harmonic of 832 seconds.
ISP frequently over subscribe customers so I would expect some uncontrollable time of day effects due to internet traffic.
I used locator to pick the approximate center point of the Serial Read data points. I then used date -r to convert the numerical value to PDT:iomelt robertlane$ date -r 1344754940Sun Aug 12 00:02:20 PDT 2012iomelt robertlane$ date -r 1345101995Thu Aug 16 00:26:35 PDT 2012iomelt robertlane$ date -r 1345370444Sun Aug 19 03:00:44 PDT 2012iomelt robertlane$ date -r 1345529140Mon Aug 20 23:05:40 PDT 2012The do not occur at the same time every day.Before you get lost in the details of the individual trees, you should answer some questions:
- Why are random rewrites faster than serial writes?
- Why are random rereads slower than serial reads?
- Why is there such a large gap in read and write times?
|
50Mb |
1,17Gb |
Serial Write Calls/s |
1981,95 |
2143,91 |
Serial Read Calls/s |
157878,50 |
52598,55 |
Random Rewrite Calls/s |
4937,62 |
209,05 |
Random Reread Calls/s |
15256,07 |
424,45 |
Random Mixed Read/Write Calls/s |
6765,20 |
231,04 |
Serial write is the least affected but serial write throughput is almost three times bigger on the smaller file.
I was amazed by the other results though, I imagined that lseek() would be a problem in the larger file but did not expect it to be such a big problem.
This is what amazed me the most:
Finished all tests
Total wallclock time: 3672.165418
CPU user/system time: 1.095833/31.895151
I will definitely double check this, but I was getting more than 97% iowait during the tests which demonstrates that the provider's infrastructure is heavily overloaded.
BTW, I ran these tests in a local VPS provider, so don't blame for the AWS EBS mayhem of yesterday… ;)
Here is a histogram with overlaid density plot.Some of your plots show multiple modes and striations in the data that do not appear with this data set. You need to be able to explain the differences.Bob
On Wednesday, October 17, 2012 5:15:52 AM UTC-7, Rodrigo Campos wrote:
--
You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To view this discussion on the web visit https://groups.google.com/d/msg/guerrilla-capacity-planning/-/D7bZFbSob70J.
To post to this group, send email to guerrilla-cap...@googlegroups.com.
To unsubscribe from this group, send email to guerrilla-capacity-...@googlegroups.com.
Just giving a heads up as I've published a new set of results using the Provisioned IOPS EBS volumes.It seems that Amazon has put a good deal of effort into the latency and performance fluctuation problems.Provisioned IOPS volumes really do deliver a more consistent, higher performance IO.That being said, you'll still get some annoying variance on larger volumes. It seems that as volumes grow and data is more and more scattered among the underlying disks, your volumes will be more susceptible to performance fluctuations.Please let me know your thoughts, I'll be more than happy to answer any questions.Best,
To unsubscribe from this group, send email to guerrilla-capacity-planning+unsub...@googlegroups.com.