The best starting point is to look at the data collected by the first two counters. How do you use the data from these counters to troubleshoot the problem? Now let’s get back to our opening scenario…your panicking end users are flooding your phone lines with reports of their inability to connect to their mailboxes. Once a problem happens, how do you interpret the collected data? Should not be greater than 25 milliseconds during a sampling period # of RPC operations that the server received in the past secondĪverage time (in milliseconds) that it took for the last 1,024 packets to be processed Should not be greater than 70 during a sampling period # of RPC threads currently in use, which also indicates the # of clients that are requesting data Be sure to set the monitoring system to throw off alerts when the counters cross the desired limit.
Once an issue arises and your troubleshooting process is in place you can add additional counters to the list. I recommend that you start by monitoring the following three RPC counters. Proper monitoring and alerting will enable you to step in and take action before this undesirable event happens. In most cases this will cause the service to shut down completely. End users connect and disconnect to individual RPC threads as they perform operations from their Outlook, such as reading and sending e-mail, creating appointments and tasks, and viewing calendars.Īn important point to note is that if the service is not functioning properly, the allocated 500 threads can quickly get used up.If the service is functioning properly, 500 threads should be more than enough. The service is automatically allocated 500 RPC threads.Booting up the server or starting the service will set the whole process in motion.
Microsoft Exchange Information Store service (store.exe) starts up.Understanding how things work is the first step towards proper monitoring and successful troubleshooting. How does Exchange prepare itself to handle Outlook requests? If not corrected, problems with RPC can lead to problems for your end users. If you want to ensure that Outlook always works properly for your end users, an important thing to monitor is RPC, the protocol that allows your Outlook and Exchange servers to “talk” to each other. The answer is to put monitoring systems and alerts in place so that you can proactively resolve issues before they become major problems. How can you avoid or minimize this less than desirable situation? Have I spotted a bug in Exchange IIS? Is this expected? Has my recycling helped? Don’t know yet.Getting support calls from Outlook clients who are not able to connect to their mailboxes always raises the crisis level to the highest level. The replacement process is consuming less memory Let’s jump into IIS, into application pools, and program some thread recycling for the thread: Let’s open the PID showing high memory usage to see if it gives us a clue:ĭo we have a memory leak? Not sure, and without any web references we’re flying blind. Let’s fire it up, and look for our W3WP processes: With headscratchers like this, Process Explorer is always a good bet. On a server with two heavy users, that seems a tad high! One process was consuming more than 500MB alone. I checked the Wordfish Exchange server and noticed high memory usage in particular W3WP processes were consuming more memory than store.exe !Ī quick Google produced nothing of note the total memory usage was 1GB.
0 kommentar(er)
