Hello girls (at least Marion) and guys (at least Dimitri ;-)
Has anyone already used the IObench script delivered with STAT_Service on linux server? It gives me no datas.
I would like to compare benchmarks carried out on a physical server and a VM. For network I/O, i was thinking about iperf solution. Do you know any benchmark tools for stressing disk, and why not CPU, RAM, postgres db?
The IObench is shipped within dim_STAT since.. (don't remember which version ;-)) - you may start it directly from the command line ( it'll print you many options) - this tool was made to generate an I/O load according various needs. The most simple way to use it is first to generate a test scenario via web interface (the link is placed on the very first welcome page) - it'll generate you a shell script to execute. And then start this script when you already collecting IObench stats from the same server - you'll be able to graph the results live and correlate them to the "iostat" and other system metrics. The shell script is simply executing IObench commands ( and you may always re-edit it if needed).
For PgSQL (and databases generally) - there is dbSTRESS. Working same way via web interface and shell script. Details about both tools are available directly from http://finitely.free.fr - let me know if you need more info. BTW, all MySQL and PgSQL benchmark results presented on my site were obtained with dbSTRESS ;-))
On Wednesday, June 8, 2011, stephane <stephane.haudebo...@gmail.com> wrote: > Hello girls (at least Marion) and guys (at least Dimitri ;-)
> Has anyone already used the IObench script delivered with STAT_Service on linux server? > It gives me no datas.
> I would like to compare benchmarks carried out on a physical server and a VM. > For network I/O, i was thinking about iperf solution. > Do you know any benchmark tools for stressing disk, and why not CPU, RAM, postgres db?
> Cheers > Stephane
> -- > You received this message because you are subscribed to the Google Groups "dim_STAT" group. > To post to this group, send email to dimstat@googlegroups.com. > To unsubscribe from this group, send email to dimstat+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/dimstat?hl=en.
On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> wrote: > Hi Stephane :-)
> The IObench is shipped within dim_STAT since.. (don't remember which > version ;-)) - you may start it directly from the command line ( it'll > print you many options) - this tool was made to generate an I/O load > according various needs. The most simple way to use it is first to > generate a test scenario via web interface (the link is placed on the > very first welcome page) - it'll generate you a shell script to > execute. And then start this script when you already collecting > IObench stats from the same server - you'll be able to graph the > results live and correlate them to the "iostat" and other system > metrics. The shell script is simply executing IObench commands ( and > you may always re-edit it if needed).
> For PgSQL (and databases generally) - there is dbSTRESS. Working same > way via web interface and shell script. Details about both tools are > available directly from http://finitely.free.fr - let me know if you > need more info. BTW, all MySQL and PgSQL benchmark results presented > on my site were obtained with dbSTRESS ;-))
> Rgds, > -Dimitri
> On Wednesday, June 8, 2011, stephane <stephane.haudebo...@gmail.com> > wrote: > > Hello girls (at least Marion) and guys (at least Dimitri ;-)
> > Has anyone already used the IObench script delivered with STAT_Service on > linux server? > > It gives me no datas.
> > I would like to compare benchmarks carried out on a physical server and a > VM. > > For network I/O, i was thinking about iperf solution. > > Do you know any benchmark tools for stressing disk, and why not CPU, RAM, > postgres db?
> > Cheers > > Stephane
> > -- > > You received this message because you are subscribed to the Google Groups > "dim_STAT" group. > > To post to this group, send email to dimstat@googlegroups.com. > > To unsubscribe from this group, send email to > dimstat+unsubscribe@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/dimstat?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "dim_STAT" group. > To post to this group, send email to dimstat@googlegroups.com. > To unsubscribe from this group, send email to > dimstat+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dimstat?hl=en.
On Fri, Jun 10, 2011 at 9:37 AM, stephane <stephane.haudebo...@gmail.com> wrote: > Thanks a lot, Dimitri
> Http link doesn't work, but i will try your directives asap.
> I find another way to use your software each week, that 's nice ;-))
> Thanks again > Stef
> On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> wrote:
>> Hi Stephane :-)
>> The IObench is shipped within dim_STAT since.. (don't remember which >> version ;-)) - you may start it directly from the command line ( it'll >> print you many options) - this tool was made to generate an I/O load >> according various needs. The most simple way to use it is first to >> generate a test scenario via web interface (the link is placed on the >> very first welcome page) - it'll generate you a shell script to >> execute. And then start this script when you already collecting >> IObench stats from the same server - you'll be able to graph the >> results live and correlate them to the "iostat" and other system >> metrics. The shell script is simply executing IObench commands ( and >> you may always re-edit it if needed).
>> For PgSQL (and databases generally) - there is dbSTRESS. Working same >> way via web interface and shell script. Details about both tools are >> available directly from http://finitely.free.fr - let me know if you >> need more info. BTW, all MySQL and PgSQL benchmark results presented >> on my site were obtained with dbSTRESS ;-))
>> Rgds, >> -Dimitri
>> On Wednesday, June 8, 2011, stephane <stephane.haudebo...@gmail.com> >> wrote: >> > Hello girls (at least Marion) and guys (at least Dimitri ;-)
>> > Has anyone already used the IObench script delivered with STAT_Service >> > on linux server? >> > It gives me no datas.
>> > I would like to compare benchmarks carried out on a physical server and >> > a VM. >> > For network I/O, i was thinking about iperf solution. >> > Do you know any benchmark tools for stressing disk, and why not CPU, >> > RAM, postgres db?
>> > Cheers >> > Stephane
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups "dim_STAT" group. >> > To post to this group, send email to dimstat@googlegroups.com. >> > To unsubscribe from this group, send email to >> > dimstat+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/dimstat?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "dim_STAT" group. >> To post to this group, send email to dimstat@googlegroups.com. >> To unsubscribe from this group, send email to >> dimstat+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/dimstat?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "dim_STAT" group. > To post to this group, send email to dimstat@googlegroups.com. > To unsubscribe from this group, send email to > dimstat+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dimstat?hl=en.
> On Fri, Jun 10, 2011 at 9:37 AM, stephane <stephane.haudebo...@gmail.com> > wrote: > > Thanks a lot, Dimitri
> > Http link doesn't work, but i will try your directives asap.
> > I find another way to use your software each week, that 's nice ;-))
> > Thanks again > > Stef
> > On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> wrote:
> >> Hi Stephane :-)
> >> The IObench is shipped within dim_STAT since.. (don't remember which > >> version ;-)) - you may start it directly from the command line ( it'll > >> print you many options) - this tool was made to generate an I/O load > >> according various needs. The most simple way to use it is first to > >> generate a test scenario via web interface (the link is placed on the > >> very first welcome page) - it'll generate you a shell script to > >> execute. And then start this script when you already collecting > >> IObench stats from the same server - you'll be able to graph the > >> results live and correlate them to the "iostat" and other system > >> metrics. The shell script is simply executing IObench commands ( and > >> you may always re-edit it if needed).
> >> For PgSQL (and databases generally) - there is dbSTRESS. Working same > >> way via web interface and shell script. Details about both tools are > >> available directly from http://finitely.free.fr - let me know if you > >> need more info. BTW, all MySQL and PgSQL benchmark results presented > >> on my site were obtained with dbSTRESS ;-))
> >> Rgds, > >> -Dimitri
> >> On Wednesday, June 8, 2011, stephane <stephane.haudebo...@gmail.com> > >> wrote: > >> > Hello girls (at least Marion) and guys (at least Dimitri ;-)
> >> > Has anyone already used the IObench script delivered with STAT_Service > >> > on linux server? > >> > It gives me no datas.
> >> > I would like to compare benchmarks carried out on a physical server > and > >> > a VM. > >> > For network I/O, i was thinking about iperf solution. > >> > Do you know any benchmark tools for stressing disk, and why not CPU, > >> > RAM, postgres db?
> >> > Cheers > >> > Stephane
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "dim_STAT" group. > >> > To post to this group, send email to dimstat@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > dimstat+unsubscribe@googlegroups.com. > >> > For more options, visit this group at > >> > http://groups.google.com/group/dimstat?hl=en.
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "dim_STAT" group. > >> To post to this group, send email to dimstat@googlegroups.com. > >> To unsubscribe from this group, send email to > >> dimstat+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/dimstat?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > > "dim_STAT" group. > > To post to this group, send email to dimstat@googlegroups.com. > > To unsubscribe from this group, send email to > > dimstat+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/dimstat?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "dim_STAT" group. > To post to this group, send email to dimstat@googlegroups.com. > To unsubscribe from this group, send email to > dimstat+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dimstat?hl=en.
> On Fri, Jun 10, 2011 at 9:37 AM, stephane <stephane.haudebo...@gmail.com> > wrote: >> Thanks a lot, Dimitri
>> Http link doesn't work, but i will try your directives asap.
>> I find another way to use your software each week, that 's nice ;-))
>> Thanks again >> Stef
>> On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> wrote:
>>> Hi Stephane :-)
>>> The IObench is shipped within dim_STAT since.. (don't remember which >>> version ;-)) - you may start it directly from the command line ( it'll >>> print you many options) - this tool was made to generate an I/O load >>> according various needs. The most simple way to use it is first to >>> generate a test scenario via web interface (the link is placed on the >>> very first welcome page) - it'll generate you a shell script to >>> execute. And then start this script when you already collecting >>> IObench stats from the same server - you'll be able to graph the >>> results live and correlate them to the "iostat" and other system >>> metrics. The shell script is simply executing IObench commands ( and >>> you may always re-edit it if needed).
>>> For PgSQL (and databases generally) - there is dbSTRESS. Working same >>> way via web interface and shell script. Details about both tools are >>> available directly from http://finitely.free.fr - let me know if you >>> need more info. BTW, all MySQL and PgSQL benchmark results presented >>> on my site were obtained with dbSTRESS ;-))
>>> Rgds, >>> -Dimitri
>>> On Wednesday, June 8, 2011, stephane <stephane.haudebo...@gmail.com> >>> wrote: >>> > Hello girls (at least Marion) and guys (at least Dimitri ;-)
>>> > Has anyone already used the IObench script delivered with STAT_Service >>> > on linux server? >>> > It gives me no datas.
>>> > I would like to compare benchmarks carried out on a physical server and >>> > a VM. >>> > For network I/O, i was thinking about iperf solution. >>> > Do you know any benchmark tools for stressing disk, and why not CPU, >>> > RAM, postgres db?
>>> > Cheers >>> > Stephane
>>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "dim_STAT" group. >>> > To post to this group, send email to dimstat@googlegroups.com. >>> > To unsubscribe from this group, send email to >>> > dimstat+unsubscribe@googlegroups.com. >>> > For more options, visit this group at >>> > http://groups.google.com/group/dimstat?hl=en.
>>> -- >>> You received this message because you are subscribed to the Google Groups >>> "dim_STAT" group. >>> To post to this group, send email to dimstat@googlegroups.com. >>> To unsubscribe from this group, send email to >>> dimstat+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/dimstat?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "dim_STAT" group. >> To post to this group, send email to dimstat@googlegroups.com. >> To unsubscribe from this group, send email to >> dimstat+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/dimstat?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "dim_STAT" group. > To post to this group, send email to dimstat@googlegroups.com. > To unsubscribe from this group, send email to > dimstat+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dimstat?hl=en.
I would have some more questions about usage of IOBench. I am bit lost with this benchmark.
Actually, i am looking for the maximum I/O that can handle a disk. How to do that? For writing indicator, is it the write/s or the TotalWs? Moreover, it shoudl depend on I/O size and number of I/O processes, but i could not retrive theses parametes on the GUI.
> > On Fri, Jun 10, 2011 at 9:37 AM, stephane <stephane.haudebo...@gmail.com
> > wrote: > >> Thanks a lot, Dimitri
> >> Http link doesn't work, but i will try your directives asap.
> >> I find another way to use your software each week, that 's nice ;-))
> >> Thanks again > >> Stef
> >> On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> wrote:
> >>> Hi Stephane :-)
> >>> The IObench is shipped within dim_STAT since.. (don't remember which > >>> version ;-)) - you may start it directly from the command line ( it'll > >>> print you many options) - this tool was made to generate an I/O load > >>> according various needs. The most simple way to use it is first to > >>> generate a test scenario via web interface (the link is placed on the > >>> very first welcome page) - it'll generate you a shell script to > >>> execute. And then start this script when you already collecting > >>> IObench stats from the same server - you'll be able to graph the > >>> results live and correlate them to the "iostat" and other system > >>> metrics. The shell script is simply executing IObench commands ( and > >>> you may always re-edit it if needed).
> >>> For PgSQL (and databases generally) - there is dbSTRESS. Working same > >>> way via web interface and shell script. Details about both tools are > >>> available directly from http://finitely.free.fr - let me know if you > >>> need more info. BTW, all MySQL and PgSQL benchmark results presented > >>> on my site were obtained with dbSTRESS ;-))
> >>> Rgds, > >>> -Dimitri
> >>> On Wednesday, June 8, 2011, stephane <stephane.haudebo...@gmail.com> > >>> wrote: > >>> > Hello girls (at least Marion) and guys (at least Dimitri ;-)
> >>> > Has anyone already used the IObench script delivered with > STAT_Service > >>> > on linux server? > >>> > It gives me no datas.
> >>> > I would like to compare benchmarks carried out on a physical server > and > >>> > a VM. > >>> > For network I/O, i was thinking about iperf solution. > >>> > Do you know any benchmark tools for stressing disk, and why not CPU, > >>> > RAM, postgres db?
> >>> > Cheers > >>> > Stephane
> >>> > -- > >>> > You received this message because you are subscribed to the Google > >>> > Groups "dim_STAT" group. > >>> > To post to this group, send email to dimstat@googlegroups.com. > >>> > To unsubscribe from this group, send email to > >>> > dimstat+unsubscribe@googlegroups.com. > >>> > For more options, visit this group at > >>> > http://groups.google.com/group/dimstat?hl=en.
> >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "dim_STAT" group. > >>> To post to this group, send email to dimstat@googlegroups.com. > >>> To unsubscribe from this group, send email to > >>> dimstat+unsubscribe@googlegroups.com. > >>> For more options, visit this group at > >>> http://groups.google.com/group/dimstat?hl=en.
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "dim_STAT" group. > >> To post to this group, send email to dimstat@googlegroups.com. > >> To unsubscribe from this group, send email to > >> dimstat+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/dimstat?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > > "dim_STAT" group. > > To post to this group, send email to dimstat@googlegroups.com. > > To unsubscribe from this group, send email to > > dimstat+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/dimstat?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "dim_STAT" group. > To post to this group, send email to dimstat@googlegroups.com. > To unsubscribe from this group, send email to > dimstat+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dimstat?hl=en.
it's the main rule for every benchmark - first of all you have to understand what exactly you want to test :-))
Regarding I/O performance: - if your goal is to reach the max possible I/O operations/sec: you have to use small block size (similar to transactional workload on databases)
- if your goal to reach the max possible throughput: you have to use big block sizes (1MB for ex., similar to DWH on databases)
- if your storage is able to process several I/O operations in parallel: for sure you'll not reach its max performance with a single I/O process activity, you'll need more than one :-)
Then according your goals, you're preparing your test scenario and looking for Op/sec or MB/sec levels..
The main goal of IObench is not to execute a "fixed" workload and give you a result.. - its goal to help to simulate the I/O activity you're expecting to see or looking for limitations, etc. - you may even prepare several scenarios and run them in parallel just to see if there is any performance impact when one kind of I/O activity is meeting another one.. In most of cases you're limited only by your imagination ;-))
Rgds, -Dimitri
On 6/15/11, stephane <stephane.haudebo...@gmail.com> wrote:
> I would have some more questions about usage of IOBench. > I am bit lost with this benchmark.
> Actually, i am looking for the maximum I/O that can handle a disk. > How to do that? For writing indicator, is it the write/s or the TotalWs? > Moreover, it shoudl depend on I/O size and number of I/O processes, but i > could not retrive theses parametes on the GUI.
> Thanks again for your support > Stephane
> On Fri, Jun 10, 2011 at 10:22, Dimitri <dimitrik...@gmail.com> wrote:
>> Thanks Matthieu! :-)
>> seems "dimitrik" in the http link was auto-replaced by check speller >> and I did not pay attention :-)
>> > On Fri, Jun 10, 2011 at 9:37 AM, stephane <stephane.haudebo...@gmail.com
>> > wrote: >> >> Thanks a lot, Dimitri
>> >> Http link doesn't work, but i will try your directives asap.
>> >> I find another way to use your software each week, that 's nice ;-))
>> >> Thanks again >> >> Stef
>> >> On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> wrote:
>> >>> Hi Stephane :-)
>> >>> The IObench is shipped within dim_STAT since.. (don't remember which >> >>> version ;-)) - you may start it directly from the command line ( it'll >> >>> print you many options) - this tool was made to generate an I/O load >> >>> according various needs. The most simple way to use it is first to >> >>> generate a test scenario via web interface (the link is placed on the >> >>> very first welcome page) - it'll generate you a shell script to >> >>> execute. And then start this script when you already collecting >> >>> IObench stats from the same server - you'll be able to graph the >> >>> results live and correlate them to the "iostat" and other system >> >>> metrics. The shell script is simply executing IObench commands ( and >> >>> you may always re-edit it if needed).
>> >>> For PgSQL (and databases generally) - there is dbSTRESS. Working same >> >>> way via web interface and shell script. Details about both tools are >> >>> available directly from http://finitely.free.fr - let me know if you >> >>> need more info. BTW, all MySQL and PgSQL benchmark results presented >> >>> on my site were obtained with dbSTRESS ;-))
>> >>> Rgds, >> >>> -Dimitri
>> >>> On Wednesday, June 8, 2011, stephane <stephane.haudebo...@gmail.com> >> >>> wrote: >> >>> > Hello girls (at least Marion) and guys (at least Dimitri ;-)
>> >>> > Has anyone already used the IObench script delivered with >> STAT_Service >> >>> > on linux server? >> >>> > It gives me no datas.
>> >>> > I would like to compare benchmarks carried out on a physical server >> and >> >>> > a VM. >> >>> > For network I/O, i was thinking about iperf solution. >> >>> > Do you know any benchmark tools for stressing disk, and why not CPU, >> >>> > RAM, postgres db?
>> >>> > Cheers >> >>> > Stephane
>> >>> > -- >> >>> > You received this message because you are subscribed to the Google >> >>> > Groups "dim_STAT" group. >> >>> > To post to this group, send email to dimstat@googlegroups.com. >> >>> > To unsubscribe from this group, send email to >> >>> > dimstat+unsubscribe@googlegroups.com. >> >>> > For more options, visit this group at >> >>> > http://groups.google.com/group/dimstat?hl=en.
>> >>> -- >> >>> You received this message because you are subscribed to the Google >> Groups >> >>> "dim_STAT" group. >> >>> To post to this group, send email to dimstat@googlegroups.com. >> >>> To unsubscribe from this group, send email to >> >>> dimstat+unsubscribe@googlegroups.com. >> >>> For more options, visit this group at >> >>> http://groups.google.com/group/dimstat?hl=en.
>> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "dim_STAT" group. >> >> To post to this group, send email to dimstat@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> dimstat+unsubscribe@googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/dimstat?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "dim_STAT" group. >> > To post to this group, send email to dimstat@googlegroups.com. >> > To unsubscribe from this group, send email to >> > dimstat+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/dimstat?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "dim_STAT" group. >> To post to this group, send email to dimstat@googlegroups.com. >> To unsubscribe from this group, send email to >> dimstat+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/dimstat?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "dim_STAT" group. > To post to this group, send email to dimstat@googlegroups.com. > To unsubscribe from this group, send email to > dimstat+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dimstat?hl=en.
It is getting clearer. Your mail confirms me that i started to understand yestarerday, that is great ;-)
Moreover, I was a bit confused to see all these test cases in the GUI. But it seems the first one (for instance: RWrnd:RW-001) is the only one to take into account.
On Wed, Jun 15, 2011 at 23:08, Dimitri <dimitrik...@gmail.com> wrote: > Hi Stephane,
> it's the main rule for every benchmark - first of all you have to > understand what exactly you want to test :-))
> Regarding I/O performance: > - if your goal is to reach the max possible I/O operations/sec: you > have to use small block size (similar to transactional workload on > databases)
> - if your goal to reach the max possible throughput: you have to use > big block sizes (1MB for ex., similar to DWH on databases)
> - if your storage is able to process several I/O operations in > parallel: for sure you'll not reach its max performance with a single > I/O process activity, you'll need more than one :-)
> Then according your goals, you're preparing your test scenario and > looking for Op/sec or MB/sec levels..
> The main goal of IObench is not to execute a "fixed" workload and give > you a result.. - its goal to help to simulate the I/O activity you're > expecting to see or looking for limitations, etc. - you may even > prepare several scenarios and run them in parallel just to see if > there is any performance impact when one kind of I/O activity is > meeting another one.. In most of cases you're limited only by your > imagination ;-))
> Rgds, > -Dimitri
> On 6/15/11, stephane <stephane.haudebo...@gmail.com> wrote: > > Hi Dimitri
> > It is me again.
> > I would have some more questions about usage of IOBench. > > I am bit lost with this benchmark.
> > Actually, i am looking for the maximum I/O that can handle a disk. > > How to do that? For writing indicator, is it the write/s or the TotalWs? > > Moreover, it shoudl depend on I/O size and number of I/O processes, but i > > could not retrive theses parametes on the GUI.
> > Thanks again for your support > > Stephane
> > On Fri, Jun 10, 2011 at 10:22, Dimitri <dimitrik...@gmail.com> wrote:
> >> Thanks Matthieu! :-)
> >> seems "dimitrik" in the http link was auto-replaced by check speller > >> and I did not pay attention :-)
> >> > On Fri, Jun 10, 2011 at 9:37 AM, stephane < > stephane.haudebo...@gmail.com
> >> > wrote: > >> >> Thanks a lot, Dimitri
> >> >> Http link doesn't work, but i will try your directives asap.
> >> >> I find another way to use your software each week, that 's nice ;-))
> >> >> Thanks again > >> >> Stef
> >> >> On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> > wrote:
> >> >>> Hi Stephane :-)
> >> >>> The IObench is shipped within dim_STAT since.. (don't remember which > >> >>> version ;-)) - you may start it directly from the command line ( > it'll > >> >>> print you many options) - this tool was made to generate an I/O load > >> >>> according various needs. The most simple way to use it is first to > >> >>> generate a test scenario via web interface (the link is placed on > the > >> >>> very first welcome page) - it'll generate you a shell script to > >> >>> execute. And then start this script when you already collecting > >> >>> IObench stats from the same server - you'll be able to graph the > >> >>> results live and correlate them to the "iostat" and other system > >> >>> metrics. The shell script is simply executing IObench commands ( and > >> >>> you may always re-edit it if needed).
> >> >>> For PgSQL (and databases generally) - there is dbSTRESS. Working > same > >> >>> way via web interface and shell script. Details about both tools are > >> >>> available directly from http://finitely.free.fr - let me know if > you > >> >>> need more info. BTW, all MySQL and PgSQL benchmark results presented > >> >>> on my site were obtained with dbSTRESS ;-))
> >> >>> Rgds, > >> >>> -Dimitri
> >> >>> On Wednesday, June 8, 2011, stephane <stephane.haudebo...@gmail.com
> >> >>> wrote: > >> >>> > Hello girls (at least Marion) and guys (at least Dimitri ;-)
> >> >>> > Has anyone already used the IObench script delivered with > >> STAT_Service > >> >>> > on linux server? > >> >>> > It gives me no datas.
> >> >>> > I would like to compare benchmarks carried out on a physical > server > >> and > >> >>> > a VM. > >> >>> > For network I/O, i was thinking about iperf solution. > >> >>> > Do you know any benchmark tools for stressing disk, and why not > CPU, > >> >>> > RAM, postgres db?
> >> >>> > Cheers > >> >>> > Stephane
> >> >>> > -- > >> >>> > You received this message because you are subscribed to the Google > >> >>> > Groups "dim_STAT" group. > >> >>> > To post to this group, send email to dimstat@googlegroups.com. > >> >>> > To unsubscribe from this group, send email to > >> >>> > dimstat+unsubscribe@googlegroups.com. > >> >>> > For more options, visit this group at > >> >>> > http://groups.google.com/group/dimstat?hl=en.
> >> >>> -- > >> >>> You received this message because you are subscribed to the Google > >> Groups > >> >>> "dim_STAT" group. > >> >>> To post to this group, send email to dimstat@googlegroups.com. > >> >>> To unsubscribe from this group, send email to > >> >>> dimstat+unsubscribe@googlegroups.com. > >> >>> For more options, visit this group at > >> >>> http://groups.google.com/group/dimstat?hl=en.
> >> >> -- > >> >> You received this message because you are subscribed to the Google > >> Groups > >> >> "dim_STAT" group. > >> >> To post to this group, send email to dimstat@googlegroups.com. > >> >> To unsubscribe from this group, send email to > >> >> dimstat+unsubscribe@googlegroups.com. > >> >> For more options, visit this group at > >> >> http://groups.google.com/group/dimstat?hl=en.
> >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "dim_STAT" group. > >> > To post to this group, send email to dimstat@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > dimstat+unsubscribe@googlegroups.com. > >> > For more options, visit this group at > >> > http://groups.google.com/group/dimstat?hl=en.
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "dim_STAT" group. > >> To post to this group, send email to dimstat@googlegroups.com. > >> To unsubscribe from this group, send email to > >> dimstat+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/dimstat?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > > "dim_STAT" group. > > To post to this group, send email to dimstat@googlegroups.com. > > To unsubscribe from this group, send email to > > dimstat+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/dimstat?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "dim_STAT" group. > To post to this group, send email to dimstat@googlegroups.com. > To unsubscribe from this group, send email to > dimstat+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dimstat?hl=en.
I am still with my I/O disk questions ;-) Sorry to ask you this question, but i could not find any response anywhere else: so here is my question: Is I/O size used within the I/O Bench test the same than the block size of ext fs? If so, i guess the bench doesn't acces directly to the FS to be able to test different I/O size.
Moreover, i find a little bug in the iostat delivered within Stat service. Indeed, for RAID disk, it shows me a Percent busy > 100% (the OS embeded iostat is ok)
Thank you for your support Stephane
On Thu, Jun 16, 2011 at 09:43, stephane <stephane.haudebo...@gmail.com>wrote:
> It is getting clearer. Your mail confirms me that i started to understand > yestarerday, that is great ;-)
> Moreover, I was a bit confused to see all these test cases in the GUI. But > it seems the first one (for instance: RWrnd:RW-001) is the only one to take > into account.
> See you > Stephane
> On Wed, Jun 15, 2011 at 23:08, Dimitri <dimitrik...@gmail.com> wrote:
>> Hi Stephane,
>> it's the main rule for every benchmark - first of all you have to >> understand what exactly you want to test :-))
>> Regarding I/O performance: >> - if your goal is to reach the max possible I/O operations/sec: you >> have to use small block size (similar to transactional workload on >> databases)
>> - if your goal to reach the max possible throughput: you have to use >> big block sizes (1MB for ex., similar to DWH on databases)
>> - if your storage is able to process several I/O operations in >> parallel: for sure you'll not reach its max performance with a single >> I/O process activity, you'll need more than one :-)
>> Then according your goals, you're preparing your test scenario and >> looking for Op/sec or MB/sec levels..
>> The main goal of IObench is not to execute a "fixed" workload and give >> you a result.. - its goal to help to simulate the I/O activity you're >> expecting to see or looking for limitations, etc. - you may even >> prepare several scenarios and run them in parallel just to see if >> there is any performance impact when one kind of I/O activity is >> meeting another one.. In most of cases you're limited only by your >> imagination ;-))
>> Rgds, >> -Dimitri
>> On 6/15/11, stephane <stephane.haudebo...@gmail.com> wrote: >> > Hi Dimitri
>> > It is me again.
>> > I would have some more questions about usage of IOBench. >> > I am bit lost with this benchmark.
>> > Actually, i am looking for the maximum I/O that can handle a disk. >> > How to do that? For writing indicator, is it the write/s or the TotalWs? >> > Moreover, it shoudl depend on I/O size and number of I/O processes, but >> i >> > could not retrive theses parametes on the GUI.
>> > Thanks again for your support >> > Stephane
>> > On Fri, Jun 10, 2011 at 10:22, Dimitri <dimitrik...@gmail.com> wrote:
>> >> Thanks Matthieu! :-)
>> >> seems "dimitrik" in the http link was auto-replaced by check speller >> >> and I did not pay attention :-)
>> >> > On Fri, Jun 10, 2011 at 9:37 AM, stephane < >> stephane.haudebo...@gmail.com
>> >> > wrote: >> >> >> Thanks a lot, Dimitri
>> >> >> Http link doesn't work, but i will try your directives asap.
>> >> >> I find another way to use your software each week, that 's nice ;-))
>> >> >> Thanks again >> >> >> Stef
>> >> >> On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> >> wrote:
>> >> >>> Hi Stephane :-)
>> >> >>> The IObench is shipped within dim_STAT since.. (don't remember >> which >> >> >>> version ;-)) - you may start it directly from the command line ( >> it'll >> >> >>> print you many options) - this tool was made to generate an I/O >> load >> >> >>> according various needs. The most simple way to use it is first to >> >> >>> generate a test scenario via web interface (the link is placed on >> the >> >> >>> very first welcome page) - it'll generate you a shell script to >> >> >>> execute. And then start this script when you already collecting >> >> >>> IObench stats from the same server - you'll be able to graph the >> >> >>> results live and correlate them to the "iostat" and other system >> >> >>> metrics. The shell script is simply executing IObench commands ( >> and >> >> >>> you may always re-edit it if needed).
>> >> >>> For PgSQL (and databases generally) - there is dbSTRESS. Working >> same >> >> >>> way via web interface and shell script. Details about both tools >> are >> >> >>> available directly from http://finitely.free.fr - let me know if >> you >> >> >>> need more info. BTW, all MySQL and PgSQL benchmark results >> presented >> >> >>> on my site were obtained with dbSTRESS ;-))
>> >> >>> Rgds, >> >> >>> -Dimitri
>> >> >>> On Wednesday, June 8, 2011, stephane < >> stephane.haudebo...@gmail.com> >> >> >>> wrote: >> >> >>> > Hello girls (at least Marion) and guys (at least Dimitri ;-)
>> >> >>> > Has anyone already used the IObench script delivered with >> >> STAT_Service >> >> >>> > on linux server? >> >> >>> > It gives me no datas.
>> >> >>> > I would like to compare benchmarks carried out on a physical >> server >> >> and >> >> >>> > a VM. >> >> >>> > For network I/O, i was thinking about iperf solution. >> >> >>> > Do you know any benchmark tools for stressing disk, and why not >> CPU, >> >> >>> > RAM, postgres db?
>> >> >>> > Cheers >> >> >>> > Stephane
>> >> >>> > -- >> >> >>> > You received this message because you are subscribed to the >> Google >> >> >>> > Groups "dim_STAT" group. >> >> >>> > To post to this group, send email to dimstat@googlegroups.com. >> >> >>> > To unsubscribe from this group, send email to >> >> >>> > dimstat+unsubscribe@googlegroups.com. >> >> >>> > For more options, visit this group at >> >> >>> > http://groups.google.com/group/dimstat?hl=en.
>> >> >>> -- >> >> >>> You received this message because you are subscribed to the Google >> >> Groups >> >> >>> "dim_STAT" group. >> >> >>> To post to this group, send email to dimstat@googlegroups.com. >> >> >>> To unsubscribe from this group, send email to >> >> >>> dimstat+unsubscribe@googlegroups.com. >> >> >>> For more options, visit this group at >> >> >>> http://groups.google.com/group/dimstat?hl=en.
>> >> >> -- >> >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> >> "dim_STAT" group. >> >> >> To post to this group, send email to dimstat@googlegroups.com. >> >> >> To unsubscribe from this group, send email to >> >> >> dimstat+unsubscribe@googlegroups.com. >> >> >> For more options, visit this group at >> >> >> http://groups.google.com/group/dimstat?hl=en.
>> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups >> >> > "dim_STAT" group. >> >> > To post to this group, send email to dimstat@googlegroups.com. >> >> > To unsubscribe from this group, send email to >> >> > dimstat+unsubscribe@googlegroups.com. >> >> > For more options, visit this group at >> >> > http://groups.google.com/group/dimstat?hl=en.
>> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "dim_STAT" group. >> >> To post to this group, send email to dimstat@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> dimstat+unsubscribe@googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/dimstat?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "dim_STAT" group. >> > To post to this group, send email to dimstat@googlegroups.com. >> > To unsubscribe from this group, send email to >> > dimstat+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/dimstat?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "dim_STAT" group. >> To post to this group, send email to dimstat@googlegroups.com. >> To unsubscribe from this group, send email to >> dimstat+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/dimstat?hl=en.
* for block size: if you're trying to simulate a real application you may use a block size which is used by this application.. If no - you may try different block sizes to see which one will give you a better performance. If you're using buffering I/O (not sync) - a "smart" filesystem group your blocks in bigger chunks, or even use Direct I/O bypassing cache buffer in some cases (like VxFS). If you're using EXTn (ext3? ext4?) on Linux - you have also pay attention for the IO scheduler you're using (cfq, noop, deadline) - depending on your linux distro performance may vary a lot..
as well, when you use a bigger block size than FS block size, different FS will manage it different way - some will split it by FS blocks, some will keep initial I/O block size and manage it as a single I/O operation.. - and this is one of the reasons to test I/O level to understand how the things are working in your case :-))
* regarding "iostat" - it's not a bug, it's just one more example of the famous "linux compatibility" :-)) as you may imagine, the existing "iostat" program worked well until now on other distros, etc. - but seems on you linux something was "improved" on the system level making a previous stuff uncompatible.. - before it was already happened to "mpstat", and you may see 800% CPU usage in "top" as well :-))
if "embedded iostat" prints the same columns - just edit /etc/STATsrv/access file and point it to the right (embedded) command. Otherwise, you may always add it as a new Add-On and share it with others :-))
Rgds, -Dimitri
On 6/21/11, stephane <stephane.haudebo...@gmail.com> wrote:
> I am still with my I/O disk questions ;-) > Sorry to ask you this question, but i could not find any response anywhere > else: > so here is my question: > Is I/O size used within the I/O Bench test the same than the block size of > ext fs? > If so, i guess the bench doesn't acces directly to the FS to be able to test > different I/O size.
> Moreover, i find a little bug in the iostat delivered within Stat service. > Indeed, for RAID disk, it shows me a Percent busy > 100% (the OS embeded > iostat is ok)
> Thank you for your support > Stephane
> On Thu, Jun 16, 2011 at 09:43, stephane > <stephane.haudebo...@gmail.com>wrote:
>> Thanks Dimitri.
>> It is getting clearer. Your mail confirms me that i started to understand >> yestarerday, that is great ;-)
>> Moreover, I was a bit confused to see all these test cases in the GUI. But >> it seems the first one (for instance: RWrnd:RW-001) is the only one to >> take >> into account.
>> See you >> Stephane
>> On Wed, Jun 15, 2011 at 23:08, Dimitri <dimitrik...@gmail.com> wrote:
>>> Hi Stephane,
>>> it's the main rule for every benchmark - first of all you have to >>> understand what exactly you want to test :-))
>>> Regarding I/O performance: >>> - if your goal is to reach the max possible I/O operations/sec: you >>> have to use small block size (similar to transactional workload on >>> databases)
>>> - if your goal to reach the max possible throughput: you have to use >>> big block sizes (1MB for ex., similar to DWH on databases)
>>> - if your storage is able to process several I/O operations in >>> parallel: for sure you'll not reach its max performance with a single >>> I/O process activity, you'll need more than one :-)
>>> Then according your goals, you're preparing your test scenario and >>> looking for Op/sec or MB/sec levels..
>>> The main goal of IObench is not to execute a "fixed" workload and give >>> you a result.. - its goal to help to simulate the I/O activity you're >>> expecting to see or looking for limitations, etc. - you may even >>> prepare several scenarios and run them in parallel just to see if >>> there is any performance impact when one kind of I/O activity is >>> meeting another one.. In most of cases you're limited only by your >>> imagination ;-))
>>> Rgds, >>> -Dimitri
>>> On 6/15/11, stephane <stephane.haudebo...@gmail.com> wrote: >>> > Hi Dimitri
>>> > It is me again.
>>> > I would have some more questions about usage of IOBench. >>> > I am bit lost with this benchmark.
>>> > Actually, i am looking for the maximum I/O that can handle a disk. >>> > How to do that? For writing indicator, is it the write/s or the >>> > TotalWs? >>> > Moreover, it shoudl depend on I/O size and number of I/O processes, but >>> i >>> > could not retrive theses parametes on the GUI.
>>> > Thanks again for your support >>> > Stephane
>>> > On Fri, Jun 10, 2011 at 10:22, Dimitri <dimitrik...@gmail.com> wrote:
>>> >> Thanks Matthieu! :-)
>>> >> seems "dimitrik" in the http link was auto-replaced by check speller >>> >> and I did not pay attention :-)
>>> >> > On Fri, Jun 10, 2011 at 9:37 AM, stephane < >>> stephane.haudebo...@gmail.com
>>> >> > wrote: >>> >> >> Thanks a lot, Dimitri
>>> >> >> Http link doesn't work, but i will try your directives asap.
>>> >> >> I find another way to use your software each week, that 's nice >>> >> >> ;-))
>>> >> >> Thanks again >>> >> >> Stef
>>> >> >> On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> >>> wrote:
>>> >> >>> Hi Stephane :-)
>>> >> >>> The IObench is shipped within dim_STAT since.. (don't remember >>> which >>> >> >>> version ;-)) - you may start it directly from the command line ( >>> it'll >>> >> >>> print you many options) - this tool was made to generate an I/O >>> load >>> >> >>> according various needs. The most simple way to use it is first to >>> >> >>> generate a test scenario via web interface (the link is placed on >>> the >>> >> >>> very first welcome page) - it'll generate you a shell script to >>> >> >>> execute. And then start this script when you already collecting >>> >> >>> IObench stats from the same server - you'll be able to graph the >>> >> >>> results live and correlate them to the "iostat" and other system >>> >> >>> metrics. The shell script is simply executing IObench commands ( >>> and >>> >> >>> you may always re-edit it if needed).
>>> >> >>> For PgSQL (and databases generally) - there is dbSTRESS. Working >>> same >>> >> >>> way via web interface and shell script. Details about both tools >>> are >>> >> >>> available directly from http://finitely.free.fr - let me know if >>> you >>> >> >>> need more info. BTW, all MySQL and PgSQL benchmark results >>> presented >>> >> >>> on my site were obtained with dbSTRESS ;-))
>>> >> >>> Rgds, >>> >> >>> -Dimitri
>>> >> >>> On Wednesday, June 8, 2011, stephane < >>> stephane.haudebo...@gmail.com> >>> >> >>> wrote: >>> >> >>> > Hello girls (at least Marion) and guys (at least Dimitri ;-)
>>> >> >>> > Has anyone already used the IObench script delivered with >>> >> STAT_Service >>> >> >>> > on linux server? >>> >> >>> > It gives me no datas.
>>> >> >>> > I would like to compare benchmarks carried out on a physical >>> server >>> >> and >>> >> >>> > a VM. >>> >> >>> > For network I/O, i was thinking about iperf solution. >>> >> >>> > Do you know any benchmark tools for stressing disk, and why not >>> CPU, >>> >> >>> > RAM, postgres db?
>>> >> >>> > Cheers >>> >> >>> > Stephane
>>> >> >>> > -- >>> >> >>> > You received this message because you are subscribed to the >>> Google >>> >> >>> > Groups "dim_STAT" group. >>> >> >>> > To post to this group, send email to dimstat@googlegroups.com. >>> >> >>> > To unsubscribe from this group, send email to >>> >> >>> > dimstat+unsubscribe@googlegroups.com. >>> >> >>> > For more options, visit this group at >>> >> >>> > http://groups.google.com/group/dimstat?hl=en.
>>> >> >>> -- >>> >> >>> You received this message because you are subscribed to the Google >>> >> Groups >>> >> >>> "dim_STAT" group. >>> >> >>> To post to this group, send email to dimstat@googlegroups.com. >>> >> >>> To unsubscribe from this group, send email to >>> >> >>> dimstat+unsubscribe@googlegroups.com. >>> >> >>> For more options, visit this group at >>> >> >>> http://groups.google.com/group/dimstat?hl=en.
>>> >> >> -- >>> >> >> You received this message because you are subscribed to the Google >>> >> Groups >>> >> >> "dim_STAT" group. >>> >> >> To post to this group, send email to dimstat@googlegroups.com. >>> >> >> To unsubscribe from this group, send email to >>> >> >> dimstat+unsubscribe@googlegroups.com. >>> >> >> For more options, visit this group at >>> >> >> http://groups.google.com/group/dimstat?hl=en.
>>> >> > -- >>> >> > You received this message because you are subscribed to the Google >>> >> > Groups >>> >> > "dim_STAT" group. >>> >> > To post to this group, send email to dimstat@googlegroups.com. >>> >> > To unsubscribe from this group, send email to >>> >> > dimstat+unsubscribe@googlegroups.com. >>> >> > For more options, visit this group at >>> >> > http://groups.google.com/group/dimstat?hl=en.
>>> >> -- >>> >> You received this message because you are subscribed to the Google >>> Groups >>> >> "dim_STAT" group. >>> >> To post to this group, send email to dimstat@googlegroups.com. >>> >> To unsubscribe from this group, send email to >>> >> dimstat+unsubscribe@googlegroups.com. >>> >> For more options, visit this group at
On Wed, Jun 22, 2011 at 09:11, Dimitri <dimitrik...@gmail.com> wrote: > Hi Stephane,
> don't worry, no problem for questions :-)
> * for block size: if you're trying to simulate a real application you > may use a block size which is used by this application.. If no - you > may try different block sizes to see which one will give you a better > performance. If you're using buffering I/O (not sync) - a "smart" > filesystem group your blocks in bigger chunks, or even use Direct I/O > bypassing cache buffer in some cases (like VxFS). If you're using EXTn > (ext3? ext4?) on Linux - you have also pay attention for the IO > scheduler you're using (cfq, noop, deadline) - depending on your linux > distro performance may vary a lot..
> as well, when you use a bigger block size than FS block size, > different FS will manage it different way - some will split it by FS > blocks, some will keep initial I/O block size and manage it as a > single I/O operation.. - and this is one of the reasons to test I/O > level to understand how the things are working in your case :-))
> * regarding "iostat" - it's not a bug, it's just one more example of > the famous "linux compatibility" :-)) as you may imagine, the > existing "iostat" program worked well until now on other distros, etc. > - but seems on you linux something was "improved" on the system level > making a previous stuff uncompatible.. - before it was already > happened to "mpstat", and you may see 800% CPU usage in "top" as well > :-))
> if "embedded iostat" prints the same columns - just edit > /etc/STATsrv/access file and point it to the right (embedded) command. > Otherwise, you may always add it as a new Add-On and share it with > others :-))
> Rgds, > -Dimitri
> On 6/21/11, stephane <stephane.haudebo...@gmail.com> wrote: > > Hi Dimitry
> > I am still with my I/O disk questions ;-) > > Sorry to ask you this question, but i could not find any response > anywhere > > else: > > so here is my question: > > Is I/O size used within the I/O Bench test the same than the block size > of > > ext fs? > > If so, i guess the bench doesn't acces directly to the FS to be able to > test > > different I/O size.
> > Moreover, i find a little bug in the iostat delivered within Stat > service. > > Indeed, for RAID disk, it shows me a Percent busy > 100% (the OS embeded > > iostat is ok)
> > Thank you for your support > > Stephane
> > On Thu, Jun 16, 2011 at 09:43, stephane > > <stephane.haudebo...@gmail.com>wrote:
> >> Thanks Dimitri.
> >> It is getting clearer. Your mail confirms me that i started to > understand > >> yestarerday, that is great ;-)
> >> Moreover, I was a bit confused to see all these test cases in the GUI. > But > >> it seems the first one (for instance: RWrnd:RW-001) is the only one to > >> take > >> into account.
> >> See you > >> Stephane
> >> On Wed, Jun 15, 2011 at 23:08, Dimitri <dimitrik...@gmail.com> wrote:
> >>> Hi Stephane,
> >>> it's the main rule for every benchmark - first of all you have to > >>> understand what exactly you want to test :-))
> >>> Regarding I/O performance: > >>> - if your goal is to reach the max possible I/O operations/sec: you > >>> have to use small block size (similar to transactional workload on > >>> databases)
> >>> - if your goal to reach the max possible throughput: you have to use > >>> big block sizes (1MB for ex., similar to DWH on databases)
> >>> - if your storage is able to process several I/O operations in > >>> parallel: for sure you'll not reach its max performance with a single > >>> I/O process activity, you'll need more than one :-)
> >>> Then according your goals, you're preparing your test scenario and > >>> looking for Op/sec or MB/sec levels..
> >>> The main goal of IObench is not to execute a "fixed" workload and give > >>> you a result.. - its goal to help to simulate the I/O activity you're > >>> expecting to see or looking for limitations, etc. - you may even > >>> prepare several scenarios and run them in parallel just to see if > >>> there is any performance impact when one kind of I/O activity is > >>> meeting another one.. In most of cases you're limited only by your > >>> imagination ;-))
> >>> Rgds, > >>> -Dimitri
> >>> On 6/15/11, stephane <stephane.haudebo...@gmail.com> wrote: > >>> > Hi Dimitri
> >>> > It is me again.
> >>> > I would have some more questions about usage of IOBench. > >>> > I am bit lost with this benchmark.
> >>> > Actually, i am looking for the maximum I/O that can handle a disk. > >>> > How to do that? For writing indicator, is it the write/s or the > >>> > TotalWs? > >>> > Moreover, it shoudl depend on I/O size and number of I/O processes, > but > >>> i > >>> > could not retrive theses parametes on the GUI.
> >>> > Thanks again for your support > >>> > Stephane
> >>> > On Fri, Jun 10, 2011 at 10:22, Dimitri <dimitrik...@gmail.com> > wrote:
> >>> >> Thanks Matthieu! :-)
> >>> >> seems "dimitrik" in the http link was auto-replaced by check speller > >>> >> and I did not pay attention :-)
> >>> >> >> Http link doesn't work, but i will try your directives asap.
> >>> >> >> I find another way to use your software each week, that 's nice > >>> >> >> ;-))
> >>> >> >> Thanks again > >>> >> >> Stef
> >>> >> >> On Fri, Jun 10, 2011 at 08:29, Dimitri <dimitrik...@gmail.com> > >>> wrote:
> >>> >> >>> Hi Stephane :-)
> >>> >> >>> The IObench is shipped within dim_STAT since.. (don't remember > >>> which > >>> >> >>> version ;-)) - you may start it directly from the command line ( > >>> it'll > >>> >> >>> print you many options) - this tool was made to generate an I/O > >>> load > >>> >> >>> according various needs. The most simple way to use it is first > to > >>> >> >>> generate a test scenario via web interface (the link is placed > on > >>> the > >>> >> >>> very first welcome page) - it'll generate you a shell script to > >>> >> >>> execute. And then start this script when you already collecting > >>> >> >>> IObench stats from the same server - you'll be able to graph the > >>> >> >>> results live and correlate them to the "iostat" and other system > >>> >> >>> metrics. The shell script is simply executing IObench commands ( > >>> and > >>> >> >>> you may always re-edit it if needed).
> >>> >> >>> For PgSQL (and databases generally) - there is dbSTRESS. Working > >>> same > >>> >> >>> way via web interface and shell script. Details about both tools > >>> are > >>> >> >>> available directly from http://finitely.free.fr - let me know > if > >>> you > >>> >> >>> need more info. BTW, all MySQL and PgSQL benchmark results > >>> presented > >>> >> >>> on my site were obtained with dbSTRESS ;-))
> >>> >> >>> Rgds, > >>> >> >>> -Dimitri
> >>> >> >>> On Wednesday, June 8, 2011, stephane < > >>> stephane.haudebo...@gmail.com> > >>> >> >>> wrote: > >>> >> >>> > Hello girls (at least Marion) and guys (at least Dimitri ;-)
> >>> >> >>> > Has anyone already used the IObench script delivered with > >>> >> STAT_Service > >>> >> >>> > on linux server? > >>> >> >>> > It gives me no datas.
> >>> >> >>> > I would like to compare benchmarks carried out on a physical > >>> server > >>> >> and > >>> >> >>> > a VM. > >>> >> >>> > For network I/O, i was thinking about iperf solution. > >>> >> >>> > Do you know any benchmark tools for stressing disk, and why > not > >>> CPU, > >>> >> >>> > RAM, postgres db?
> >>> >> >>> > Cheers > >>> >> >>> > Stephane
> >>> >> >>> > -- > >>> >> >>> > You received this message because you are subscribed to the > >>> Google > >>> >> >>> > Groups "dim_STAT" group. > >>> >> >>> > To post to this group, send email to dimstat@googlegroups.com > . > >>> >> >>> > To unsubscribe from this group, send email to > >>> >> >>> > dimstat+unsubscribe@googlegroups.com. > >>> >> >>> > For more options, visit this group at > >>> >> >>> > http://groups.google.com/group/dimstat?hl=en.
> >>> >> >>> -- > >>> >> >>> You received this message because you are subscribed to the > Google > >>> >> Groups > >>> >> >>> "dim_STAT" group. > >>> >> >>> To post to this group, send email to dimstat@googlegroups.com. > >>> >> >>> To unsubscribe from this group, send email to > >>> >> >>> dimstat+unsubscribe@googlegroups.com. > >>> >> >>> For more options, visit this group at > >>> >> >>> http://groups.google.com/group/dimstat?hl=en.
> >>> >> >> -- > >>> >> >> You received this message because you are subscribed to the > Google > >>> >> Groups > >>> >> >> "dim_STAT" group. > >>> >> >> To post to this group, send email to dimstat@googlegroups.com. > >>> >> >> To unsubscribe from this group, send email to > >>> >> >> dimstat+unsubscribe@googlegroups.com. > >>> >> >> For more options, visit this group at > >>> >> >> http://groups.google.com/group/dimstat?hl=en.
