我遇到了一个非常严重的问题与服务器。 我们的服务器之前是非常快的。 但是这周它变得越来越慢。 每天晚些时候，w3wp进程会停止，我们不能再次连接到共享点。 当没有人使用Sharepoint服务器时，我们监视进程，发现内存使用量越来越大。 然后我们检查一下sharepoint的日志，会有内存泄漏。 我想知道，如何找出导致内存泄漏的原因？ 什么导致服务器变得越来越慢？
最好的祝福，
你有没有编写自己的Web部件，工作stream程或事件？
如果是这样，请运行SPDisposeCheck工具来帮助您检查使用SharePoint API的程序集，以便正确处理内存
code.msdn.microsoft.com/SPDisposeCheck
要么
你有没有安装任何更新本周检查控制面板？
每天下午在同一时间？ 看看那个时候你有什么预定的工作，或许明天就把他们全部禁用，看看事情是否有所改善。 不知何故，你必须缩小哪些组件造成了问题。
此外，请检查您的任务pipe理器，以查看进程csrss.exe是否使用高CPU> 90％。 在MS中有一个logging的错误，如果用户帐户被损坏，它会旋转。 该修补程序是一种“无法修复”，因为它涉及永久删除您可能无法正确备份的内容！ 以下是链接到微软的MSDN网站：
“csrss代表”客户端/服务器运行时子系统。
这是Win32子系统的用户模式部分（Win32.sys是内核模式部分）。 Csrss是必须始终运行的基本子系统。 Csrs负责控制台窗口，创build和/或删除线程，以及16位虚拟MS-DOS环境的某些部分。“
参考
检查应用程序池的内存大小是否有exception，特别是networking花园的数量。 我敢打赌，你有10个左右的东西， 如果这样减less到1或2将立即解决的事情。
首先使用性能计数器来检查由w3wp.exe和owstimer.exe进程使用的内存。 这些进程是唯一应该与SharePoint相关的进程。 （这里有很多计数器的列表，但是把它们一起使用可能没有多大帮助。）
一旦确认问题出现在其中一个进程中，请确认问题是.NET代码中的内存泄漏。 特别是＃Gen 2 Collections监视器是一个很可能的迹象，表明内存不被释放。 这里有其他监视器的一个很好的总结 。
最后，检查哪个自定义代码泄漏内存。 正如克里斯提到的， SPDisposeCheck是检查内存是否被正确处置的一个非常好的方法。 你可以运行它对一个特定的自定义DLL，并迅速find罪魁祸首。 请注意，有时会出现误报，但从不会出现假阴性。
你有一个Firefox浏览器在服务器上闲置吗？ 我发现 – 一贯的 – 如果我忘记closures我的火狐浏览器在晚上，第二天早上，我的服务器爬行缓慢，如果我放了24小时，它没有反应。
（编者注：我使用浏览器进行pipe理 – 我不需要使用浏览器，尽pipe我可以做也没有太大的影响。）
如果我每天closures浏览器，它将无限期地运行。
鼠标甚至不会移动，并忘记提供网页。 我的configuration大概是这样的：
我寻找资源泄漏（手柄，内存等）和内存总是相同的〜75-80％的水平与中等分页。 I / O计数是可笑的，每刷新10K。 线程和句柄都与问题没有发生时相同。
我上网了解答案和错误报告，但没有什么是跳出来对我。
另外，我不知道其他浏览器是否有相同的效果。