Re: Requesting Data errors with SAN and Large Mailboxs
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
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 an
RE: Requesting Data errors with SAN and Large Mailboxs
Cool. Will see if this is possible. Also will try Roger's suggestion also (restore last good backup and run eseutil against it) if that doesn't work. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Atkinson, Daniel Sent: Friday, April 05, 2002 6:33 AM To: Exchange Discussions Subject: RE: Requesting Data errors with SAN and Large Mailboxs We had similar problems with our SAN after adding some new disks and assigning these to a separate non-exchange server - outlook started giving lots of 'requesting data from server' messages and other apps using the SAN for data storage also suffered poor performance. A complete shutdown and restart of the SAN cured everything. A little worrying, but that was six months ago and all is well and good since Dan. _ 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]
RE: Requesting Data errors with SAN and Large Mailboxs
We had similar problems with our SAN after adding some new disks and assigning these to a separate non-exchange server - outlook started giving lots of 'requesting data from server' messages and other apps using the SAN for data storage also suffered poor performance. A complete shutdown and restart of the SAN cured everything. A little worrying, but that was six months ago and all is well and good since Dan. _ 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]
RE: Requesting Data errors with SAN and Large Mailboxs
Restore your last good backup to your recovery server and run eseutil against the restored copy. You're checking to see if there is any corruption out in the file. -- Roger D. Seielstad - MCSE Sr. Systems Administrator Peregrine Systems Atlanta, GA > -Original Message- > From: Jim Brady [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 04, 2002 5:32 PM > To: Exchange Discussions > 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]
RE: Requesting Data errors with SAN and Large Mailboxs
Awesome information. Thanks for taking time to give some very helpful details ... appreciate the tips. Will check the KB article out and will follow from there. 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 pa
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 s
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/s
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]
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]
