You mean a disk queue length of 5 on two-spindle RAID1 for more than 5 minutes is bad? LOL. I have a client that is constantly HDD-bound (I've seen queue lengths of 15 for over 10 mins at a time - and they're not out or RAM either), running SBS2K3 on dual SATA RAID1 volumes (the OS, Exchange and SQL are on the same volume though - long story)...17 users, most of them use a SQL, all of course use Exchange. As a general rule, I don't tell people that they'll see _significant_ performance improvements regardless of what kind of upgrade they are getting be it GB switches, SSD drives, etc.
This client I _have_ told them they would see significant increase on their SQL-based app when they get a new server since it'll be 15K SAS drives and the SQL will be on a separate volume than Exchange. Dave -----Original Message----- From: Michael B. Smith [mailto:[email protected]] Sent: Tuesday, February 07, 2012 8:26 AM 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:[email protected]] 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:[email protected]] 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:[email protected]] 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:[email protected]] 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 <[email protected]> wrote: > Those perf counters can be a bit misleading when you’re looking at a > SAN on the backend, though. > > > > Thanks, > > Brian Desmond > > [email protected] > > > > w – 312.625.1438 | c – 312.731.3132 > > > > From: Michael B. Smith [mailto:[email protected]] > 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:[email protected]] > 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: [email protected] > > 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 [email protected] > 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 [email protected] > 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 [email protected] > 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] with the body: unsubscribe ntsysadmin
