SQL Server Performance Forum – Threads Archive

page faults very high for mssearch

I have been wrestling with very high page faults (20,000/sec) since migrating
from 32 bit to 64.
They look to be coming from the mssearch process,
and they look to be soft page faults, not hard page faults.
What led me to this counter is trying to figure out why our CPU usage is higher than it should be.
Is there anything I can do to eliminate the page faults.
We have 12 gig memory in the dedicated sql server machine.
8G for sql server and the rest for OS and mssearch.

Check the pagefile.sys location and if possible move it a seperate drive where SQL database files aren’t exists. Check the ‘Working set size’ value in SQL server.
Monitor the Memory: Page Faults/sec counter to make sure that the disk activity is not caused by paging. Satya SKJ
Moderator
http://www.SQL-Server-Performance.Com/forum
This posting is provided â€œAS ISâ€ with no rights for the sake of knowledge sharing.

max server memory (MB)4214748364780908090
min server memory (MB)0214748364780908090
set working set size0100 satya,
based on the above, we have sql server set to use 8G manually, not dynamically.
Should we set the ‘set working set size’ to 1?
What would this do?

BOL refers
Do not set set working set size if you are allowing SQL Server to use memory dynamically. Before setting set working set size to 1, set both min server memory and max server memory to the same value, the amount of memory you want SQL Server to use. Do not change set working set size from the default setting. With the default of 0, the Windows NT or Windows 2000 virtual memory manager can determine the working set size of SQL Server. When you install SQL Server, Setup automatically instructs Windows NT or Windows 2000 to optimize performance for network applications. The Windows NT or Windows 2000 virtual memory manager will therefore do very little working set trimming, which only minimally interferes with the working set of SQL Server instances. Changing this setting does not typically provide any performance benefit. Based on actual support cases, the changing of this setting typically causes more damage than good. REfer error log for any information related to 844 or 845 error messages. BTW do you have any performance hit during the process? Satya SKJ
Moderator
http://www.SQL-Server-Performance.Com/forum
This posting is provided â€œAS ISâ€ with no rights for the sake of knowledge sharing.

]]>