每周至少几次,我们在读取任何文件或处理服务器代码时会收到错误“没有足够的存储空间”. IIS服务器无法将路径映射到本地磁盘(不仅仅是与DFS同步的磁盘),加载组策略权限(我们收到各种错误)似乎也有问题,我们无法在任何服务器上打开任何共享在兰.从其他自定义应用程序读取文件时也存在I / O错误.这个淘汰期间的磁盘速度和延迟都可以.如果我们尝试复制文件或测试驱动器速度,通常可以正常工作.有时,我们甚至无法运行“我的电脑”或任何其他软件(例如性能监视器).它只能在我们“以管理员身份运行”时启动.每个磁盘上都有足够的存储空间.
大多数网站停止工作(但不是全部).服务器重启后,一切正常,几天后再出现问题.
使用VMWARE对服务器进行虚拟化,每个服务器上有50个IIS池(其中一些是mem限制的)和大约200个运行站点.两台服务器都有16GB的RAM(仅使用了约80％). cpu一直在30-60％之间.
我们尝试将IRPStackSize注册表属性更改为更高的数字,但没有更改.问题仍然存在.我们试图禁用防病毒(NOD) – 没有成功.
任何提示？也许我们接近IIS限制(对许多站点/池)？也许是32位操作系统和16GB内存？也许有一些’秘密’注册表设置…我们不认为每天重启是长期解决方案.
这个错误很容易重现.只需选择一堆大文件(图像或DLL或其他),右键单击并使用open-with选项用记事本打开它们.这应该占用内存的分配.当swap-file接近其最大容量时,随机服务将开始记录事件日志中没有足够的可用存储空间.他们通常会在重新启动之前一直处于故障状态.
我使用自己的服务遇到了这个问题,并且必须添加一些额外的错误处理来强制服务进程在线程上发生此类错误时退出.这样,服务将以自动方式重新启动和恢复.
IIS通常可以很好地处理这种情况(与普通的Windows服务相比).
为了找到导致这种情况发生的过程(通常是内存泄漏),您应该使用performance monitor mmc管理单元,并记录正在运行的进程的内存使用情况(在决定记录内容时要有选择性,因为这些日志文件会变得非常大) .另一个选择是使用xperf,它实际上更适合调试低级驱动程序,所以,但在这种情况下也会有所帮助.
如果结果是耗尽所有内存的w3wc服务,您可以使用Microsoft的全新Application Insights(或任何其他IIS监视工具)等工具来确定哪个应用程序池,Web应用程序或网站负责.然后,您可以限制该特定池的内存使用量,或者将其安排为优雅地回收.
IIS通常可以循环池,没有人会注意到(取决于应用程序如何处理会话,如果是自定义构建,则在刷新所有静态变量时可能会丢失会话).通常这样的解决方法足够好,并且可以避免昂贵的错误修复(免责声明：这不是解决问题的“我的风格”,但大多数利益相关者都喜欢这样).
