the article is not about SAN block size, but RAID block size. The numbers translate over nicely but nowhere in the article is SAN mentioned try "block size RAID"
----- Original Message ----- From: "Jim Brady" <[EMAIL PROTECTED]> To: "Exchange Discussions" <[EMAIL PROTECTED]> Sent: Monday, April 08, 2002 11:51 AM Subject: RE: Requesting Data errors with SAN and Large Mailboxs > One more thing ... couldn't find that KB article on SAN block size ... > remember any key works on how to search for it ... can't seem to find > it. > > Thanks ... Jim > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Daniel > Chenault > Sent: Thursday, April 04, 2002 10:58 PM > To: Exchange Discussions > Subject: Re: Requesting Data errors with SAN and Large Mailboxs > > 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] > > > _________________________________________________________________ > 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]
