Reading the graphs.
7 views
Skip to first unread message
Paul K. Dickson
May 1, 2009, 10:06:26 AM5/1/09
to vmk...@googlegroups.com
Is there any documentation anywhere on what all the graphs mean? Mainly the Blocks/s on the VMFS volumes. I don’t know how the blocks translate into megs/s etc etc.
Paul K. Dickson
Systems Administrator
Frederick County Government, IIT
pdic...@fredco-md.net
301-600-2399/x12399
Paul K. Dickson
Systems Administrator
Frederick County Government, IIT
pdic...@fredco-md.net
301-600-2399/x12399
lar...@colargol.tihlde.org
May 2, 2009, 5:33:27 AM5/2/09
to vmktree
The best documentation available for describing the values shown in
vmktree is those documented for esxtop here:
Interpreting esxtop Statistics
http://communities.vmware.com/docs/DOC-9279
Regarding your question about translating blocks/sec into Mb/sec it's
a different matter as you can't easily translate it as the block size
is not a fixed size. Still, the blocks/sec is much a more important
factor than Mb/sec when looking for bottle necks.
Storage performance is very important in a virtualized environment.
Also see my testing here: http://vmfaq.com/entry/33/
If you wonder if your storage performance is good or bad, please run
an iometer test and compare it with others in these threads:
http://communities.vmware.com/thread/73745
http://communities.vmware.com/thread/197844
Good luck!
Lars
On May 1, 4:06 pm, "Paul K. Dickson" <pdick...@fredco-md.net> wrote:
> Is there any documentation anywhere on what all the graphs mean? Mainly the
> Blocks/s on the VMFS volumes. I don¹t know how the blocks translate into
> megs/s etc etc.
>
> Paul K. Dickson
> Systems Administrator
> Frederick County Government, IIT
> pdick...@fredco-md.net
> 301-600-2399/x12399
vmktree is those documented for esxtop here:
Interpreting esxtop Statistics
http://communities.vmware.com/docs/DOC-9279
Regarding your question about translating blocks/sec into Mb/sec it's
a different matter as you can't easily translate it as the block size
is not a fixed size. Still, the blocks/sec is much a more important
factor than Mb/sec when looking for bottle necks.
Storage performance is very important in a virtualized environment.
Also see my testing here: http://vmfaq.com/entry/33/
If you wonder if your storage performance is good or bad, please run
an iometer test and compare it with others in these threads:
http://communities.vmware.com/thread/73745
http://communities.vmware.com/thread/197844
Good luck!
Lars
On May 1, 4:06 pm, "Paul K. Dickson" <pdick...@fredco-md.net> wrote:
> Is there any documentation anywhere on what all the graphs mean? Mainly the
> Blocks/s on the VMFS volumes. I don¹t know how the blocks translate into
> megs/s etc etc.
>
> Paul K. Dickson
> Systems Administrator
> Frederick County Government, IIT
> 301-600-2399/x12399
paulkd...@gmail.com
May 4, 2009, 9:52:08 AM5/4/09
to vmktree
Great! Thanks for the info. I appreciate it.
On May 2, 5:33 am, lar...@colargol.tihlde.org wrote:
> The best documentation available for describing the values shown in
> vmktree is those documented for esxtop here:
>
> Interpreting esxtop Statisticshttp://communities.vmware.com/docs/DOC-9279
On May 2, 5:33 am, lar...@colargol.tihlde.org wrote:
> The best documentation available for describing the values shown in
> vmktree is those documented for esxtop here:
>
>
> Regarding your question about translating blocks/sec into Mb/sec it's
> a different matter as you can't easily translate it as the block size
> is not a fixed size. Still, the blocks/sec is much a more important
> factor than Mb/sec when looking for bottle necks.
>
> Storage performance is very important in a virtualized environment.
> Also see my testing here:http://vmfaq.com/entry/33/
>
> If you wonder if your storage performance is good or bad, please run
> an iometer test and compare it with others in these threads:http://communities.vmware.com/thread/73745http://communities.vmware.com/thread/197844
> Regarding your question about translating blocks/sec into Mb/sec it's
> a different matter as you can't easily translate it as the block size
> is not a fixed size. Still, the blocks/sec is much a more important
> factor than Mb/sec when looking for bottle necks.
>
> Storage performance is very important in a virtualized environment.
> Also see my testing here:http://vmfaq.com/entry/33/
>
> If you wonder if your storage performance is good or bad, please run
paulkd...@gmail.com
May 4, 2009, 10:12:23 AM5/4/09
to vmktree
How can I determine if the blocks/s add up to a bottle neck?
> The best documentation available for describing the values shown in
> vmktree is those documented for esxtop here:
>
> Interpreting esxtop Statisticshttp://communities.vmware.com/docs/DOC-9279
> vmktree is those documented for esxtop here:
>
>
> Regarding your question about translating blocks/sec into Mb/sec it's
> a different matter as you can't easily translate it as the block size
> is not a fixed size. Still, the blocks/sec is much a more important
> factor than Mb/sec when looking for bottle necks.
>
> Storage performance is very important in a virtualized environment.
> Also see my testing here:http://vmfaq.com/entry/33/
>
> If you wonder if your storage performance is good or bad, please run
> an iometer test and compare it with others in these threads:http://communities.vmware.com/thread/73745http://communities.vmware.com/thread/197844
> Regarding your question about translating blocks/sec into Mb/sec it's
> a different matter as you can't easily translate it as the block size
> is not a fixed size. Still, the blocks/sec is much a more important
> factor than Mb/sec when looking for bottle necks.
>
> Storage performance is very important in a virtualized environment.
> Also see my testing here:http://vmfaq.com/entry/33/
>
> If you wonder if your storage performance is good or bad, please run
paulkd...@gmail.com
May 4, 2009, 10:13:53 AM5/4/09
to vmktree
For instance, the highest total I have for blocks/s in my cluster is
192.01. I have no idea what that means.
192.01. I have no idea what that means.
> The best documentation available for describing the values shown in
> vmktree is those documented for esxtop here:
>
> Interpreting esxtop Statisticshttp://communities.vmware.com/docs/DOC-9279
> vmktree is those documented for esxtop here:
>
>
> Regarding your question about translating blocks/sec into Mb/sec it's
> a different matter as you can't easily translate it as the block size
> is not a fixed size. Still, the blocks/sec is much a more important
> factor than Mb/sec when looking for bottle necks.
>
> Storage performance is very important in a virtualized environment.
> Also see my testing here:http://vmfaq.com/entry/33/
>
> If you wonder if your storage performance is good or bad, please run
> an iometer test and compare it with others in these threads:http://communities.vmware.com/thread/73745http://communities.vmware.com/thread/197844
> Regarding your question about translating blocks/sec into Mb/sec it's
> a different matter as you can't easily translate it as the block size
> is not a fixed size. Still, the blocks/sec is much a more important
> factor than Mb/sec when looking for bottle necks.
>
> Storage performance is very important in a virtualized environment.
> Also see my testing here:http://vmfaq.com/entry/33/
>
> If you wonder if your storage performance is good or bad, please run
paulkd...@gmail.com
May 4, 2009, 10:16:49 AM5/4/09
to vmktree
Actually, going back a week i have 1.37k blocks/s as my max. Still
no idea what that translates into perforance wise.
no idea what that translates into perforance wise.
> The best documentation available for describing the values shown in
> vmktree is those documented for esxtop here:
>
> Interpreting esxtop Statisticshttp://communities.vmware.com/docs/DOC-9279
> vmktree is those documented for esxtop here:
>
>
> Regarding your question about translating blocks/sec into Mb/sec it's
> a different matter as you can't easily translate it as the block size
> is not a fixed size. Still, the blocks/sec is much a more important
> factor than Mb/sec when looking for bottle necks.
>
> Storage performance is very important in a virtualized environment.
> Also see my testing here:http://vmfaq.com/entry/33/
>
> If you wonder if your storage performance is good or bad, please run
> an iometer test and compare it with others in these threads:http://communities.vmware.com/thread/73745http://communities.vmware.com/thread/197844
> Regarding your question about translating blocks/sec into Mb/sec it's
> a different matter as you can't easily translate it as the block size
> is not a fixed size. Still, the blocks/sec is much a more important
> factor than Mb/sec when looking for bottle necks.
>
> Storage performance is very important in a virtualized environment.
> Also see my testing here:http://vmfaq.com/entry/33/
>
> If you wonder if your storage performance is good or bad, please run
Lars Troen
May 5, 2009, 8:14:41 AM5/5/09
to vmk...@googlegroups.com
Hi,
1.37k io/s is normally not more than an average san can handle, but it depends on how many spindles you're using, the type of workload and the amount of cache on your controllers. As a rule of thumb; a 15k rpm SAS-disk can do 180io/sec, a 15k rpm scsi disk can do 150io/sec, 10k rpm SCSI can do 100 IO/sec and a SATA disk can do 50 io/sec. These numbers vary a bit with the disk types too (on-disk cache, ncq, etc..)..
For a very good deep dive in disk technology see here:
http://www.snia.org/education/tutorials/2008/spring/storage/Whittington-W_Desktop_Nearline_Enterprise_HDDS.pdf
By looking at io per second on the SAN you will not normally have enough info to determine if you have a bottle neck or not. You will often need to compare these values with latencies (as seen in esxtop: press d to go into disk view, then f to choose additional fields and make sure you choose Latency) and inside the guest OS. The value you want to look at here is GAVG/cmd.
In windows guests you can use perfmon and see the AvgDiskQueueLength. It should be close to 0 and less than 1 in environments with good performance.
You also might want to check the statistics of your SAN. I don't know what SAN you're using, but on DS4000 series (that can be monitored with vmktree) you want to check the graphs for CacheHitRatio for both the LUNs in questions and SAN controllers.
Let me know what you find out. I'm also soon be including support for DS5000 series and probably improved support for NetApp (as I now have one in the lab).
Lars
-----Original Message-----
From: vmk...@googlegroups.com [mailto:vmk...@googlegroups.com] On Behalf Of paulkd...@gmail.com
Sent: 4. mai 2009 16:17
To: vmktree
Subject: [vmktree] Re: Reading the graphs.
How can I determine if the blocks/s add up to a bottle neck?
1.37k io/s is normally not more than an average san can handle, but it depends on how many spindles you're using, the type of workload and the amount of cache on your controllers. As a rule of thumb; a 15k rpm SAS-disk can do 180io/sec, a 15k rpm scsi disk can do 150io/sec, 10k rpm SCSI can do 100 IO/sec and a SATA disk can do 50 io/sec. These numbers vary a bit with the disk types too (on-disk cache, ncq, etc..)..
For a very good deep dive in disk technology see here:
http://www.snia.org/education/tutorials/2008/spring/storage/Whittington-W_Desktop_Nearline_Enterprise_HDDS.pdf
By looking at io per second on the SAN you will not normally have enough info to determine if you have a bottle neck or not. You will often need to compare these values with latencies (as seen in esxtop: press d to go into disk view, then f to choose additional fields and make sure you choose Latency) and inside the guest OS. The value you want to look at here is GAVG/cmd.
In windows guests you can use perfmon and see the AvgDiskQueueLength. It should be close to 0 and less than 1 in environments with good performance.
You also might want to check the statistics of your SAN. I don't know what SAN you're using, but on DS4000 series (that can be monitored with vmktree) you want to check the graphs for CacheHitRatio for both the LUNs in questions and SAN controllers.
Let me know what you find out. I'm also soon be including support for DS5000 series and probably improved support for NetApp (as I now have one in the lab).
Lars
-----Original Message-----
From: vmk...@googlegroups.com [mailto:vmk...@googlegroups.com] On Behalf Of paulkd...@gmail.com
Sent: 4. mai 2009 16:17
To: vmktree
Subject: [vmktree] Re: Reading the graphs.
How can I determine if the blocks/s add up to a bottle neck?
paulkd...@gmail.com
May 11, 2009, 3:23:04 PM5/11/09
to vmktree
Thanks Lars. Great info.
On May 5, 8:14 am, Lars Troen <lars.tr...@sit.no> wrote:
> Hi,
> 1.37k io/s is normally not more than an average san can handle, but it depends on how many spindles you're using, the type of workload and the amount of cache on your controllers. As a rule of thumb; a 15k rpm SAS-disk can do 180io/sec, a 15k rpm scsi disk can do 150io/sec, 10k rpm SCSI can do 100 IO/sec and a SATA disk can do 50 io/sec. These numbers vary a bit with the disk types too (on-disk cache, ncq, etc..)..
>
> For a very good deep dive in disk technology see here:http://www.snia.org/education/tutorials/2008/spring/storage/Whittingt...
On May 5, 8:14 am, Lars Troen <lars.tr...@sit.no> wrote:
> Hi,
> 1.37k io/s is normally not more than an average san can handle, but it depends on how many spindles you're using, the type of workload and the amount of cache on your controllers. As a rule of thumb; a 15k rpm SAS-disk can do 180io/sec, a 15k rpm scsi disk can do 150io/sec, 10k rpm SCSI can do 100 IO/sec and a SATA disk can do 50 io/sec. These numbers vary a bit with the disk types too (on-disk cache, ncq, etc..)..
>
>
> By looking at io per second on the SAN you will not normally have enough info to determine if you have a bottle neck or not. You will often need to compare these values with latencies (as seen in esxtop: press d to go into disk view, then f to choose additional fields and make sure you choose Latency) and inside the guest OS. The value you want to look at here is GAVG/cmd.
>
> In windows guests you can use perfmon and see the AvgDiskQueueLength. It should be close to 0 and less than 1 in environments with good performance.
>
> You also might want to check the statistics of your SAN. I don't know what SAN you're using, but on DS4000 series (that can be monitored with vmktree) you want to check the graphs for CacheHitRatio for both the LUNs in questions and SAN controllers.
>
> Let me know what you find out. I'm also soon be including support for DS5000 series and probably improved support for NetApp (as I now have one in the lab).
>
> Lars
>
> -----Original Message-----
> From: vmk...@googlegroups.com [mailto:vmk...@googlegroups.com] On Behalf Of paulkdick...@gmail.com
> Sent: 4. mai 2009 16:17
> To: vmktree
> Subject: [vmktree] Re: Reading the graphs.
>
> How can I determine if the blocks/s add up to a bottle neck?
>
> Actually, going back a week i have 1.37k blocks/s as my max. Still
> no idea what that translates into perforance wise.
>
> On May 2, 5:33 am, lar...@colargol.tihlde.org wrote:
> > The best documentation available for describing the values shown in
> > vmktree is those documented for esxtop here:
>
> > Interpreting esxtop Statisticshttp://communities.vmware.com/docs/DOC-9279
>
> > Regarding your question about translating blocks/sec into Mb/sec it's
> > a different matter as you can't easily translate it as the block size
> > is not a fixed size. Still, the blocks/sec is much a more important
> > factor than Mb/sec when looking for bottle necks.
>
> > Storage performance is very important in a virtualized environment.
> > Also see my testing here:http://vmfaq.com/entry/33/
>
> > If you wonder if your storage performance is good or bad, please run
> > an iometer test and compare it with others in these threads:http://communities.vmware.com/thread/73745http://communities.vmware.c...
> By looking at io per second on the SAN you will not normally have enough info to determine if you have a bottle neck or not. You will often need to compare these values with latencies (as seen in esxtop: press d to go into disk view, then f to choose additional fields and make sure you choose Latency) and inside the guest OS. The value you want to look at here is GAVG/cmd.
>
> In windows guests you can use perfmon and see the AvgDiskQueueLength. It should be close to 0 and less than 1 in environments with good performance.
>
> You also might want to check the statistics of your SAN. I don't know what SAN you're using, but on DS4000 series (that can be monitored with vmktree) you want to check the graphs for CacheHitRatio for both the LUNs in questions and SAN controllers.
>
> Let me know what you find out. I'm also soon be including support for DS5000 series and probably improved support for NetApp (as I now have one in the lab).
>
> Lars
>
> -----Original Message-----
> From: vmk...@googlegroups.com [mailto:vmk...@googlegroups.com] On Behalf Of paulkdick...@gmail.com
> Sent: 4. mai 2009 16:17
> To: vmktree
> Subject: [vmktree] Re: Reading the graphs.
>
> How can I determine if the blocks/s add up to a bottle neck?
>
> Actually, going back a week i have 1.37k blocks/s as my max. Still
> no idea what that translates into perforance wise.
>
> On May 2, 5:33 am, lar...@colargol.tihlde.org wrote:
> > The best documentation available for describing the values shown in
> > vmktree is those documented for esxtop here:
>
> > Interpreting esxtop Statisticshttp://communities.vmware.com/docs/DOC-9279
>
> > Regarding your question about translating blocks/sec into Mb/sec it's
> > a different matter as you can't easily translate it as the block size
> > is not a fixed size. Still, the blocks/sec is much a more important
> > factor than Mb/sec when looking for bottle necks.
>
> > Storage performance is very important in a virtualized environment.
> > Also see my testing here:http://vmfaq.com/entry/33/
>
> > If you wonder if your storage performance is good or bad, please run
Reply all
Reply to author
Forward
0 new messages