![]() Sure, and nothing else on the machine could possibly use any more than 1 GB. Therefore, if the computer is dedicated to running Exchange Server only, there is no benefit to installing more than 4 GB of memory. What real world complaints are you getting from your users about the servers performance? Slow searches? Long queue times before receiving email?Its sounds like you should run the Exchange Best Practices Analyzer on your server, if its only using <2GB of memory you likely haven't setup the server to be aware of the above 3GB that is installed for Exchange to use.įrom that KB article:quote:On a computer with 4 GB or more of physical memory, Exchange Server will not use any more than 3 GB. I'll probably get those sizes decreased first. I also noticed that some mailboxes on that small exchange server are over 10 gigs in size. My virtual memory is set to Min:9000MB Max:12000MBThere isn't a lot of CPU usage, or memory usage.So, why are Pages/Sec, and Page Faults/Sec so huge? And why isn't it storing more in the memory?Any suggestions?edit: Yekh. Average Page Faults/Sec ~200-400Avg Available Mem 3976 MegsTotal memory in the server is 6 GB, and it seems that most of it remains unused. It's not overly taxed but if you look at the performance, it shows: Average Pages/Sec greater than 55. It is a single machine, running a small exchange server and a small active directory. Quote:Originally posted by garg:I'm having a weird issue with a Server 2003 Enterprise server. Windows Server 2008 is a lot more aggressive about pre-caching memory to lower the number of hard faults, though as mentioned, you cannot eliminate them unless you can replace all hard disk with RAM. I wish there was a per-process counter for page reads/sec.If you're not noticing performance lags that affect users or business processes, none of this is a big deal. But since this counter tracks all page faults (including those that are resolved from elsewhere in memory) rather than hard faults only, it can be misleading at times. I do this sometimes, selecting all processes and then using the bar chart view. You can use the Process age Faults/sec counter and select one or more process instances. It will be a lot spikier when apps or services are initially loaded, or paged back in after long disuse.If you discover high page reads/sec and want to track it to a specific process, well, more bad news. But on a system with enough memory and well-designed apps, the Page Reads/sec graph will be spiky: short spikes to high values, with the graph returning to zero much of the time. Of course the OS can't store everything in memory, so some hard faults will still happen. ![]() Hard page faults are when the OS must read data from disk, where optimally it would have retrieved that data from physical memory. If you're worried about memory utilization, use the Memory age Reads/sec counter, which shows the number of reads from disk to resolve hard page faults. Memory => Page Faults/sec is that plus any additional kernel mode page faults.Memory ages/sec and Memory age Faults/sec are for most intents, not super-valuable counters. So Process => Page Faults/sec => _Total is a sum of all the page faults incurred by all the running user mode processes. Soft faults are not so bad because the page is still in RAM somewhere, it's just not in the process' working set and has to be retrieved from elsewhere in main memory which is much faster than going to disk. Hard faults are the ones that can cause serious performance degradation because you have to go to disk (swap file) to satisfy a hard fault. Page faults come in two flavors: soft faults and hard faults. ![]() Page faults can be satisfied at CPU IRQL 0 (all user mode and most kernel mode,) or 1 (kernel APC and page faults,) but page faults can not be satisfied at IRQL 2 (dispatch) or above. Not page faults in the kernel, for example by device drivers. Or you can select the _Total instance to get a sum of all page faults incurred by all running processes.īut even if you selected _Total, you could still only get page faults incurred by user mode processes. So you can inspect page faults incurred by one specific process. On the other hand, the counter Process => Page Faults/sec is a set of counters that has an instance for every user mode process that is running on the machine. The counter Memory => Page Faults/sec represents a system-wide count of page faults. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |