Re: [Iometer-user] Limit IOpS

[Sascha E. <fe...@do...>]

Hello Robert,

is it possible to set the delay in the ICF? I did not find anything in 
this area.

I now added a sleep_milisec(1) in the Do_IOs() of IOGrunt. First I added 
it at the end of the loop, but then it was part of the response time. I 
now moved it to the start of the transaction, so I changed around line 
1264 of trunc to be following:

         //transaction->start_IO = (grunt_state == TestRecording) ? 
timer_value() : 0;

         // If the transaction start time hasn't been set,
         // this is the first I/O of this transaction.  Set the start time.
         // ERROR(fe...@do...): This is a quick patch to limit 
to number of IOPS
         //                             generated by the dynamo. This 
should not make it
         //                             into the public sources. It 
should be possible to
         //                             turn this behaviour on/off using 
the GUI (or at
         //                             least the command line of the 
dynamo).
         if (!transaction->start_transaction) {
             sleep_milisec(1);
             transaction->start_IO = (grunt_state == TestRecording) ? 
timer_value() : 0;
             transaction->start_transaction = transaction->start_IO;
         } else {
             transaction->start_IO = (grunt_state == TestRecording) ? 
timer_value() : 0;
         }

With this I get more or less the behaviour you discribed: around 63 IOPS 
per worker. I will check how to get this up to a few hundred workers, so 
to get 5000 IOPS I will need about 80 workers, to get 100.000 IOPS it 
will be about 1600. I wonder if my machine will like this...

I think there is no good way to make it waiting a shorter amount of time?

I will be at CeBit for the rest of the week, so I think I will not be 
able to test it before next monday.

bests

Sascha

Am 28.02.2013 21:24, schrieb Robert Perry:
> You may want to start by looking at how 'delay' is handled in grunt.cpp.  You could do it now, without making any changes, but it is a bit tricky..  Start by create an ICF that has 1 worker doing I/O to one lun with 1 outstanding and set the delay to 1....   this will tell you what the actual granularity of the timing mechanism is on the host...  I found that on windows I was seeing something like 14ms...i would get ~70 iops versus 1000, but if you see something close to 1000 iops, that is great.  You can then play with multiple workers to get more iops...  I haven't done this in quite a while, but I think I used a combination of num outstanding,delay and burst to deal with the 14ms granularity and drive certain loads...
>
>
> On Feb 28, 2013, at 7:18 AM, Sascha Effert <fe...@do...> wrote:
>
>> Hello,
>>
>> I would like to measure the average and max response time of a storage
>> system (SAN with SSDs) with different load. Therefore I want iometer to
>> generate (about) 5000 IOPS (later about 10000, 20000, up to some hundred
>> thousands). Is this possible using iometer? At the moment I do not see a
>> way to solve this. Does anybody know any other tool solving this issue?
>>
>> If IOMeter does not allow to do so, I would like to play a little bit
>> with the code. Therefore I want to implement a sleep after each IO.
>> Searching the code I found the TargetDisk implementing the Read and
>> Write and the class Grunt, which is the IO worker. I am very unsure
>> where I should place the sleep. I am searching something like a look
>> where the single Requests are created. Can someone give an idea where to
>> find it?
>>
>> bests
>>
>> Sascha
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> Iometer-user mailing list
>> Iom...@li...
>> https://lists.sourceforge.net/lists/listinfo/iometer-user