Perfmon should also reveal whether the SAN is somehow slowing things down. I know a SAN is supposed to be faster but that can depend on how it was configured in the first place. I've seen a SAN being demoed that was significantly slower than it should have been. After tuning the block sizes to more closely reflect the expected block sizes being written (the demo used Exchange and this is a known size) the performance problems disappeared. Or rather was alleviated; there were some extraneous factors that prevented the demo from giving a good result (not important at this time). Bottom line is that to achieve high performance with a SAN requires more than plugging it in and turning it on. There is a KB article on selecting block size according to size of disks and number of spindles that as I recall translates nicely to SAN configuration.
There are numerous objects under Object:PhysicalDisk that, in aggregate, can give a very good idea of how the disk storage subsystem is performing. If I were to choose one as a starting point it would be Current Disk Queue Length. The Explain button for this says: "Current Disk Queue Length is the number of requests outstanding on the disk at the time the performance data is collected. It also includes requests in service at the time of the collection. This is a instantaneous snapshot, not an average over the time interval. Multi-spindle disk devices can have multiple requests that are active at one time, but other concurrent requests are awaiting service. This counter might reflect a transitory high or low queue length, but if there is a sustained load on the disk drive, it is likely that this will be consistently high. Requests experience delays proportional to the length of this queue minus the number of spindles on the disks. For good performance, this difference should average less than two. If this number were to stay high, or be on a ramp-up that never goes back down, this would indicate the disk subsystem is falling behind on servicing read/write requests (the above represents both). From here there are other counters that could be observed in order to narrow down where the slowdown is occuring. As to your other point about all the mail being elsewhere besides in the inbox. When a mailbox opens the root folder is enumerated - a large number of folders in the root would be a slowdown. Then the inbox is enumerated; ditto for a large number of messages. Then rules are fired and here is where other folders could be touched and thus enumerated. This could make for a very slow startup for Outlook. After startup the user might drag a message with the mouse to a folder; that folder gets enumerated if it hasn't already, same if a rule fires. A new message sent would write to the Sent Items folder, enumeration again. A deleted message is sent to the Deleted Items folder and, again, more enumeration. I trust that answers your question on that score. ----- Original Message ----- From: "Jim Brady" <[EMAIL PROTECTED]> To: "Exchange Discussions" <[EMAIL PROTECTED]> Sent: Thursday, April 04, 2002 10:22 PM Subject: RE: Requesting Data errors with SAN and Large Mailboxs > Thanks for the insight/understanding. I'll give perfmon a shot, and > check slipstick for some possible solutions. > > One thing ... if this started happening right after we switched to the > SAN, then I must conclude that SAN technology may not be able handle > large mailbox enumerations, etc ... agreed? But a SAN is supposed to > outperform a SCSI Raid, right? > > Also, if the user has no emails in his inbox folder (they're all in > another folder in the mailbox) ... that's not going to make a > difference, right? ... didn't think so. > > Thanks again ... Jim > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Daniel > Chenault > Sent: Thursday, April 04, 2002 7:54 PM > To: Exchange Discussions > Subject: Re: Requesting Data errors with SAN and Large Mailboxs > > I'm betting these users have tons of folders or, just as bad, a small > number > of folders with lots of messages in them. > > When a user accesses the root of his mailbox the folders in the root > level > are enumerated by the server and passed back to the client. As each > folder > is accessed (either by clicking on it, by a rule or by dragging a > message to > it) the contents of that folder are enumerated by the server and passed > back > to the client. This... takes... time... for... lots... of... messages... > or... folders. The user sees a definite slowdown and in OutlookXP will > get > the popup message you described (Outlook's communication with the server > is > single-threaded). > > Try this experiment if you can find the chance to do it. Have the user > reboot his workstation and start Outlook. Have perfmon running against > the > Exchange server watching physical memory, store usage of memory, cpu and > store use of cpu. Watch them spike up and keep ramping up. There's your > answer. > > Solution: dig through the junk and get rid of the crap (Mike, let's meet > for > lunch on 4/4/97). Come up with a logical and efficient folder hierarchy > that > reflects the users' usage of those folders. Anything not accessed in > over > six months (arbitrary number) goes to a PST (and backed up, just in > case). > > Although Exchange is generally pretty good about maintaining large > amounts > of objects and data the contents of the mailbox itself are pretty much > left > up to the user to manage. That is to say that Exchange owns the mailbox, > but > not the contents of the mailbox (in the sense of managing it). This is > usually not a problem, but then again the usual user doesn't have 65,000 > objects in his mailbox, let alone 200,000. > > I understand there are some third-party add-ons for Outlook that help > with > managing a large amount of information offering indexing, management and > archival functions; that's what's needed here. Exchange is doing what it > is > supposed to do and OL isn't intelligent enough to serve as a front-end > to a > very large store of objects. Take a look at www.slipstick.com. > > ----- Original Message ----- > From: "missy koslosky" <[EMAIL PROTECTED]> > To: "Exchange Discussions" <[EMAIL PROTECTED]> > Sent: Thursday, April 04, 2002 6:41 PM > Subject: Re: Requesting Data errors with SAN and Large Mailboxs > > > > This is more a case of sh!t happens than anything else... > > ----- Original Message ----- > > From: "Jim Brady" <[EMAIL PROTECTED]> > > To: "Exchange Discussions" <[EMAIL PROTECTED]> > > Sent: Thursday, April 04, 2002 5:32 PM > > Subject: Requesting Data errors with SAN and Large Mailboxs > > > > > > Running Exch55, Sp4, NT4, Sp5 with IS located on SAN Shark (Compaq > Fiber > > Card). Running TrendServerProtect and TrendScanMail. A certain user > > is getting a lot of latency/delays (requesting data from Microsoft > > Exchange dialog box, etc) when accessing his mailbox in Outlook (XP). > > Not a network issue, as he's tried this from multiple PC's, laptops > > (wireless), etc . same errors periodically. Plenty of free space on > the > > IS/LOG drives. No errors in the event logs. He wasn't having these > > problems before we switched to the SAN (Compaq RAID5 before). One > > caveat . this user has a 240MB mailbox with 150,000 - 200,000 > messages > > in it . so many, it's only reading as 0 messages. > > > > One other user (out of 250 on the server) has complained also. This > > user has a 3.5GB mailbox, but only 65,000 messages in it. > > > > Any ideas? > > > > Thanks, > > > > Jim > > > > > > _________________________________________________________________ > > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > > Archives: http://www.swynk.com/sitesearch/search.asp > > To unsubscribe: mailto:[EMAIL PROTECTED] > > Exchange List admin: [EMAIL PROTECTED] > > > > > > > > _________________________________________________________________ > > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > > Archives: http://www.swynk.com/sitesearch/search.asp > > To unsubscribe: mailto:[EMAIL PROTECTED] > > Exchange List admin: [EMAIL PROTECTED] > > > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
