Gets more interesting with SAN though when you have something like a Netapp FlashCache or something in the mix
Thanks, Brian Desmond br...@briandesmond.com w - 312.625.1438 | c - 312.731.3132 -----Original Message----- From: Paul Hutchings [mailto:paul.hutchi...@mira.co.uk] Sent: Tuesday, February 07, 2012 10:36 AM To: NT System Admin Issues Subject: RE: IOPS's calculations I don't think SAN vs. DAS/NAS should matter tbh, just the spindles in the array - no expert either I just muddle by. This is what I was going from - http://technet.microsoft.com/en-us/library/cc938625.aspx ________________________________________ From: Michael B. Smith [mich...@smithcons.com] Sent: 07 February 2012 4:25 PM To: NT System Admin Issues Subject: RE: IOPS's calculations I'm not a SAN expert. But for typical RAID subsystems, I don't want the physical queue to exceed the number of disks in the array. If it does, then I've got excessive queuing and degraded performance. I don't see how it would be different for a SAN, but I dunno. Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com -----Original Message----- From: Paul Hutchings [mailto:paul.hutchi...@mira.co.uk] Sent: Tuesday, February 07, 2012 10:40 AM To: NT System Admin Issues Subject: RE: IOPS's calculations Most guides I've read suggest if the LUN has 10 physical disks, you don't want the queue to exceed around 20, or if you have 5 disks a queue of 10 and so on. -----Original Message----- From: Michael B. Smith [mailto:mich...@smithcons.com] Sent: 07 February 2012 15:06 To: NT System Admin Issues Subject: RE: IOPS's calculations Where do you get "x 2" ? I was with you - until that. Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com -----Original Message----- From: Paul Hutchings [mailto:paul.hutchi...@mira.co.uk] Sent: Tuesday, February 07, 2012 8:56 AM To: NT System Admin Issues Subject: RE: IOPS's calculations As a rule of thumb queue length shouldn't exceed the physical number of disks in the array that the LUN is on x 2. -----Original Message----- From: Kurt Buff [mailto:kurt.b...@gmail.com] Sent: 07 February 2012 13:50 To: NT System Admin Issues Subject: Re: IOPS's calculations So, to which counters should I be paying attention in such a situation, or what should be the difference in interpretation? I've got a file server that's being extremely slow to back up, though daily performance is adequate. I'm seeing disk queue length hit as high as 37, with 5 LUNS for the machine. Kurt On Mon, Feb 6, 2012 at 21:32, Brian Desmond <br...@briandesmond.com> wrote: > Those perf counters can be a bit misleading when you're looking at a > SAN on the backend, though. > > > > Thanks, > > Brian Desmond > > br...@briandesmond.com > > > > w - 312.625.1438 | c - 312.731.3132 > > > > From: Michael B. Smith [mailto:mich...@smithcons.com] > Sent: Monday, February 06, 2012 3:32 PM > To: NT System Admin Issues > Subject: RE: IOPS's calculations > > > > Disk Reads per second > > Disk Writes per second > > Average Disk Queue Length > > > > I'd track both logical disk and physical disk. > > > > Regards, > > > > Michael B. Smith > > Consultant and Exchange MVP > > http://TheEssentialExchange.com > > > > From: Reimer, Mark [mailto:mark.rei...@prairie.edu] > Sent: Monday, February 06, 2012 3:56 PM > To: NT System Admin Issues > Subject: IOPS's calculations > > > > Hi folks, > > > > Thanks for all your help in the past. > > > > Looking at setting up a SAN. From my research, I think one thing to be > aware of is current IOPS (disk). There are a number of sites that will > help you determine IOPS based on what hard drives (and RAID > configuration). My question is: Many of my current servers are light > use. The IOPS that these servers are capable of is much greater than what is > actually being used. > > > > So, in order to more properly size the SAN, is there a way to > determine working IOPS? That is, what is actually being used? I assume > Perfmon would help, and will need to log over a period of time (I > think a week would be about right, to catch most scenarios). But what > counters, and how to analyze those counters? > > > > Servers are Windows 2003. > > > > Thanks. > > > > > > Mark Reimer, A+, MCSA > > Servers & Networking Admin > > Prairie Bible Institute > > Box 4000 > > Three Hills, AB T0M-2N0 > > Canada > > Tel: 403-443-5511, Ext. 3476 > > Fax: 403-443-5540 > > Email: mark.rei...@prairie.edu > > www.prairie.edu > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin -- MIRA Ltd Watling Street, Nuneaton, Warwickshire, CV10 0TU, England Registered in England and Wales No. 402570 VAT Registration GB 100 1464 84 The contents of this e-mail are confidential and are solely for the use of the intended recipient. If you receive this e-mail in error, please delete it and notify us either by e-mail, telephone or fax. You should not copy, forward or otherwise disclose the content of the e-mail as this is prohibited. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin