On 5/5/2010 12:00 PM, Karanbir Singh wrote:
>
>> Try to run the same IO operations as your production server is running.
>> Bonnie++ could be good application for benchmarking. Also run some
>> parallel rsync, rm, find, etc proccesses.
>>
>
> I am with John Pierce on this one, role and app will dictate benchmarks
> that reflect reality.
>
> Having said that, I think iozone> bonnie++

If the job involves creating/deleting lots of little files like a mail
server with maildir format storage, you might try to dig up a copy of
postmark too.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On May 5, 2010, at 1:13 PM, Les Mikesell <lesmikesell@gmail.com> wrote:

> On 5/5/2010 12:00 PM, Karanbir Singh wrote:
>>
>>> Try to run the same IO operations as your production server is
>>> running.
>>> Bonnie++ could be good application for benchmarking. Also run some
>>> parallel rsync, rm, find, etc proccesses.
>>>
>>
>> I am with John Pierce on this one, role and app will dictate
>> benchmarks
>> that reflect reality.
>>
>> Having said that, I think iozone> bonnie++
>
> If the job involves creating/deleting lots of little files like a mail
> server with maildir format storage, you might try to dig up a copy of
> postmark too.

I found iometer is a good tool for real-world benchmarking if you take
the time to setup the tests according to the workload.

-Ross

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Hi!

Use a simple test:
time dd if=/dev/zero of=/tmp/test-hd bs=1M count=1000

Sysbench:
http://sysbench.sourceforge.net/docs/#fileio_mode


And this:
http://assets.en.oreilly.com/1/event/27/Linux%20Filesystem%20Performance%20for%20Databases %20Presentation.pdf


2010/5/5 Matt Keating <keatster@gmail.com>

What is the best way to benchmark disk IO?



I'm looking to move one of my servers, which is rather IO intense. But

not without first benchmarking the current and new disk array, To make

sure this isn't a full waste of time.



thanks

_______________________________________________

CentOS mailing list

CentOS@centos.org

http://lists.centos.org/mailman/listinfo/centos



--
Best regards,

Eugene Kilimchuk <ekilimchuk@gmail.com>

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Wed, May 05, 2010 at 09:47:19AM -0700, nate wrote:
> Matt Keating wrote:
> > What is the best way to benchmark disk IO?
> >
> > I'm looking to move one of my servers, which is rather IO intense. But
> > not without first benchmarking the current and new disk array, To make
> > sure this isn't a full waste of time.
>
> You can do a pretty easy calculation based on the #/type of drives
> to determine the approx number of raw IOPS that are available, since
> it's I/O intensive your probably best off with RAID 1+0, which further
> simplifies the calculation, parity based raid can make it really
> complicated.
>
> 7200 RPM disk = ~90 IOPS
> 10000 RPM disk = ~150-180 IOPS
> 15000 RPM disk = ~230-250 IOPS
> ...

The above numbers are true if we have random (!) IO pattern.
In case of sequential (!) IO even SATA disks can deliver much, much higher numbers.


Regards
Przemyslaw Bak (przemol)
--
http://przemol.blogspot.com/





























----------------------------------------------------------------------
Szukasz pracy? Zobacz ciekawe oferty w Twoim miescie
Sprawdz >>> http://linkint.pl/f26b2

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

??????? ???????? wrote:
> Use a simple test:
> time dd if=/dev/zero of=/tmp/test-hd bs=1M count=1000

sequential cached writes, yeah, thats useful. *not*


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

przemolicc@poczta.fm wrote:
> The above numbers are true if we have random (!) IO pattern.
> In case of sequential (!) IO even SATA disks can deliver much, much higher numbers.
>


sequential IO is remarkably rare in a typical server environment

anyways, the IOPS numbers on sequential operations aren't much higher,
they are just transferring more data per operation.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

2010/5/6 John R Pierce <pierce@hogranch.com>

??????? ???????? wrote:

> Use a simple test:

> time dd if=/dev/zero of=/tmp/test-hd bs=1M count=1000



sequential cached writes, yeah, thats useful. *not*



This is
one of the steps.

You can use sysbench random read and random write for multi-thirds.


_______________________________________________

CentOS mailing list

CentOS@centos.org

http://lists.centos.org/mailman/listinfo/centos



--
Best regards,

Eugene Kilimchuk <ekilimchuk@gmail.com>

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Thu, May 06, 2010 at 12:56:55AM -0700, John R Pierce wrote:
> przemolicc@poczta.fm wrote:
> > The above numbers are true if we have random (!) IO pattern.
> > In case of sequential (!) IO even SATA disks can deliver much, much higher numbers.
> >
>
>
> sequential IO is remarkably rare in a typical server environment

Yes, of course: Oracle's redo logs which are key performance factor for all
transactions (inserts/updates) have sequential IO pattern.
And Oracle is not a typical server environment ....

> anyways, the IOPS numbers on sequential operations aren't much higher,
> they are just transferring more data per operation.

I didn't say that they _are_ much higher. I said that even SATA
disks can deliver hight IOPS on condition of sequential IO.


Regards
Przemyslaw Bak (przemol)
--
http://przemol.blogspot.com/





























----------------------------------------------------------------------
Audi kilka tysiÄ?cy zĹ?otych taniej? Przebieraj wĹ?rĂłd tysiÄ?cy ogĹ?oszeĹ?!
Sprawdz >>> http://linkint.pl/f26b3

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Thanks for all the updates. Will look into iozone and the advice given
about the rest.

2010/5/6 <przemolicc@poczta.fm>:
> On Thu, May 06, 2010 at 12:56:55AM -0700, John R Pierce wrote:
>> przemolicc@poczta.fm wrote:
>> > The above numbers are true if we have random (!) IO pattern.
>> > In case of sequential (!) IO even SATA disks can deliver much, much higher numbers.
>> >
>>
>>
>> sequential IO is remarkably rare in a typical server environment
>
> Yes, of course: Oracle's redo logs which are key performance factor for all
> transactions (inserts/updates) have sequential IO pattern.
> And Oracle is not a typical server environment ....
>
>> anyways, the IOPS numbers on sequential operations aren't much higher,
>> they are just transferring more data per operation.
>
> I didn't say that they _are_ much higher. I said that even SATA
> disks can deliver hight IOPS on condition of sequential IO.
>
>
> Regards
> Przemyslaw Bak (przemol)
> --
> http://przemol.blogspot.com/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
> Audi kilka tysiÄ cy zĹ otych taniej? Przebieraj wĹ rĂłd tysiÄ cy ogĹ oszeĹ !
> Sprawdz >>> http://linkint.pl/f26b3
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Sorry for the top post - clicked send before looking
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos