Windows – IIS7.5应用程序池回收 – .Net OutOfMemoryException

前端之家收集整理的这篇文章主要介绍了Windows – IIS7.5应用程序池回收 – .Net OutOfMemoryException前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在被攻击的应用程序的随机页面上抛出IIS / Windows 2008 R2中的.Net OutOfMemoryExceptions的奇怪情况.

我们有大约1000个独立的站点,它们是相同的.Net应用程序(每个站点有不同的代码文件夹和应用程序池).
64位Windows并运行.Net 2.0,应用程序使用’Anycpu’标志进行编译.

由于相同的确切代码适用于旧服务器并且永远不会抛出超出内存的例外,因此我们不再花费大量时间来分析应用程序并检查转储并执行有助于避免大对象堆碎片的代码优化(因此我们希望得到一些提示可能的服务器配置问题可能是罪魁祸首,而不是查看代码库并优化它…).

配置1 – Rackspace CloudSites(共享主机,我们只能FTP到它,无法访问IIS设置):

1 IIS服务器,我们无法控制它,但被告知每个应用程序池有250MB的回收限制.在我们的1000个站点中,许多站点(20-50)显然共享相同的应用程序池.
我们从来没有在这里获得OutOfMemoryExceptions,并且多年来一直在运行应用程序.

配置2 – Rackspace专用服务器(完全控制):

Monster服务器具有128GB RAM,专用,每个站点都有自己的应用程序池.所有应用程序池都具有相同的设置(350MB回收限制).
不确定这是否有影响,但此服务器上的页面文件大小为4GB(不知道Config 1有什么 – 这是否需要增加/解决?).

这两个配置在两个或三个Web服务器之间进行负载平衡,但这本身并不重要,因为我们正在查看没有TRAFFIC的站点被OutOfMemoryExceptions杀死.

这篇文章在我写的时候升级了,这里是外卖子弹

TL; DR

>增加页面文件的大小(从臀部拍摄至少40GB,如果你能负担得起磁盘容量和I / O,则更多,但请阅读底部文章)
>增加frequentHitThreshold and frequentHitTimePeriod值(查看Web服务缓存性能计数器并相应调整)
>将maxResponseSize值降低到85KB或更低,以避免大对象堆中的缓存条目
>降低应用程序池回收的内存限制,它没有多大意义
>考虑在应用程序池中对具有相同或类似代码库的应用程序进行分组

原始答案

Not sure if this is of consequence but the page file size on this sever is 4GB (no idea what Config 1 has – does this need to be increased/addressed?

这,这里^就在这里^看看它.

我愿意打赌,这正是你的应用程序抛出OutOfMemoryException以响应看似最随机和最良性的请求的原因,但为了理解原因,让我们明白一件事:

OutOfMemory并不意味着您的服务器内存不足!

我知道这听起来像个恶作剧,但事实并非如此.这不是操作系统抱怨内存耗尽 – 这是过程.
如果最后一句话对你没有意义,请继续阅读.

内存管理101

当一个进程从操作系统分配内存时,它会出现一系列称为页面的片段,每页4千字节,该进程可以将其视为自己的(这通常称为虚拟地址空间).

由于对象(例如字符串,XML文档,图像或您需要保留在内存中的任何内容)可能超过4KB的页面大小,因此该过程将需要不时地从该内存中分配多个连续页面.

但是,随着时间的推移,即使使用.NET CLR,内存空间也会变得支离破碎.垃圾收集器将尽力通过在收集期间重新安排工作集中的页面来帮助应用程序更好地利用地址空间(这实际上与磁盘碎片整理相同),但是指向大对象堆的指针例如,将保持不变.

IIS 7.x如何发挥作用

最近explained in this answer,IIS也会尝试尽可能多地存储可缓存的输出对象(例如最多256KB的静态文件),在为您的应用程序提供服务的同一过程中 – 除了该答案中的建议外,您还可以尝试使用<serverRuntime>配置元素调整缓存频率阈值.

在任何情况下,IIS 7.5 – 在其默认配置中 – 都非常关心为其工作进程分配足够的内存,即使使用“NO TRAFFIC”,在工作进程旋转时工作进程声称第一个100MB的情况并不罕见,即使是磁盘上稍微小一点的应用程序代码库.

这与页面文件有什么关系?

不需要研究生水平的数学才能看到100MB * 1000的进程与操作系统提供的128GB RAM相差不远.尽管IIS尝试根据需要为其工作进程分配尽可能多的内存,但它在某些时候停止为操作系统留出一些空间,大约占安装总内存的85%,无论可能有多少兆兆字节或几千兆字节的内存.是(这不是我见过文档的事实,而是从具有不同硬件规格的大量IIS安装的第一手经验中得出).

此时,操作系统可以通过分配页面文件中的页面来帮助释放内存,而不是将页面存储在物理磁盘上的文件中.由于磁盘容量通常很大,分配大块磁盘存储并不是什么大不了的事,但如果它需要为1000个进程分页内存并且只允许在4GB空间内这样做,那么它不需要很长时间进程将无法分配更长的非碎片内存和粉扑序列!:进程抛出OutOfMemoryException,它只是意味着它无法在其可访问的虚拟地址空间中找到足够的相邻页面.

它甚至不必是大型物体.它们只需要大于运行时可用的最大连续页面数.从理论上讲,您可以获得一个OutOfMemory异常,以尝试将单个字符附加到当前大小超过2KB的字符串.

那么Pagefile大小应该设置为什么?

微软一直回答这个问题:“它取决于”,但至少1 x RAM 257MB(这是系统需要能够写入完整内存转储的存储量).

经验法则似乎在1.5-2 x RAM左右,但这又取决于,并且已经发表了许多关于如何确定给定系统上正确的最小和最大页面文件大小的文章.我在底部包含了最相关的一个.

确保监视包含页面文件的磁盘,如果磁盘队列长度计数器开始加扰,您可能希望将其移动到专用磁盘,或将其分散到多个磁盘上.

How to determine the appropriate page file size for 64-bit versions of Windows

原文链接:https://www.f2er.com/windows/368932.html

猜你在找的Windows相关文章