最近很多小伙伴都在问Windows–IIS7.5应用程序池回收–.NetOutOfMemoryException和iis应用程序池回收作用这两个问题，那么本篇文章就来给大家详细解答一下，同时本文还将给
最近很多小伙伴都在问Windows – IIS7.5应用程序池回收 – .Net OutOfMemoryException和iis应用程序池回收作用这两个问题，那么本篇文章就来给大家详细解答一下，同时本文还将给你拓展"System.OutOfMemoryException" exception when you execute a query in SQL Server Manageme...、.net – 创建数组时的SystemOutOfMemoryException、.net – 移动设备上的OutOfMemoryException、.NET陷阱之五：奇怪的OutOfMemoryException——大对象堆引起的问题与对策等相关知识，下面开始了哦！
本文目录一览：- Windows – IIS7.5应用程序池回收 – .Net OutOfMemoryException（iis应用程序池回收作用）
- "System.OutOfMemoryException" exception when you execute a query in SQL Server Manageme...
- .net – 创建数组时的SystemOutOfMemoryException
- .net – 移动设备上的OutOfMemoryException
- .NET陷阱之五：奇怪的OutOfMemoryException——大对象堆引起的问题与对策
Windows – IIS7.5应用程序池回收 – .Net OutOfMemoryException（iis应用程序池回收作用）
我们有大约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
"System.OutOfMemoryException" exception when you execute a query in SQL Server Manageme...
Symptoms
When you use Microsoft SQL Server Management Studio (SSMS) to run an SQL query that returns a large amount of data, you receive an error message that resembles the following:
An error occurred while executing batch. Error message is: Exception of type ''System.OutOfMemoryException'' was thrown
Cause
This issue occurs because SSMS has insufficient memory to allocate for large results.
Note SSMS is a 32-bit process. Therefore, it is limited to 2 GB of memory. SSMS imposes an artificial limit on how much text that can be displayed per database field in the results window. This limit is 64 KB in "Grid" mode and 8 KB in "Text" mode. If the result set is too large, the memory that is required to display the query results may surpass the 2 GB limit of the SSMS process. Therefore, a large result set can cause the error that is mentioned in the "Symptoms" section.
Workaround
To work around this issue, try one of the following methods.
Method 1: Output the results as text
Configure the query window to output the query results as text. A text output uses less memory than the grid, and it may be sufficient to display the query results. To make this change, follow these steps:
- Right-click the query window.
- Click Results to.
- Click Results to Text.
Method 2: Output the results to a file
Configure the query window to output the query results to a file. A file output uses a minimal amount of memory. This reserves more memory for storing the results set. To make this change, follow these steps:
- Right-click the query window.
- Click Results to.
- Click Results To File.
- Run the query, and then select the location in which to save the results file.
Method 3: Use sqlcmd
Use the sqlcmd tool instead of SSMS to run the SQL queries. This method enables queries to be run without the resources that are required by the SSMS UI. Additionally, you can use the 64-bit version of Sqlcmd.exe to avoid the memory restriction that affects the 32-bit SSMS process.
原文链接
.net – 创建数组时的SystemOutOfMemoryException
这是代码(请不要判断代码,不是我的代码至少7年)
Dim myFiletoUpload As New IO.FileInfo(IO.Path.Combine(m_Path,filename))
Dim myFileStream As IO.FileStream
Try
myFileStream = myFiletoUpload.OpenRead
Dim bytes As Long = myFileStream.Length //(Length is roughly 308 million)
If bytes > 0 Then
Dim data(bytes - 1) As Byte // OutOfMemoryException is caught here
myFileStream.Read(data,bytes)
objInfo.content = data
End If
Catch ex As Exception
Throw ex
Finally
myFileStream.Close()
End Try
根据这个问题“SO Max Size of .Net Arrays”和这个问题“Maximum lenght of an array”,最大长度为2,147,483,647个元素或Int32.MaxValue,最大大小为2 GB
所以我的阵列的总长度完全在限制范围内(3.08亿< 20亿),而且我的大小也小于2 GB(文件大小为298 mb). 题：
所以我的问题,关于数组还有什么可能导致MemoryOutOfMemoryException？
注意：对于那些想知道服务器仍然有一些10GB的免费ram空间
注2：在dude’s advice之后,我在几次运行中监控了GDI对象的数量.进程本身永远不会超过计数1500个对象.
例如,在我的机器上,我不能在一个阵列中分配超过908 000 000字节,但如果存储在更多阵列中,我可以毫无问题地分配100 * 90 800 000：
// alocation in one array
byte[] toBigArray = new byte[908000000]; //doesn't work (6 zeroes after 908)
// allocation in more arrays
byte[][] a=new byte[100][];
for (int i = 0 ; i<a.Length;i++) // it works even there is 10x more memory needed than before
{
a[0] = new byte[90800000]; // (5 zeroes after 908)
}
.net – 移动设备上的OutOfMemoryException
public static Bitmap TakePicture()
{
var dialog = new CameraCaptureDialog
{
Resolution = new Size(1600,1200),StillQuality = CameraCaptureStillQuality.Default
};
dialog.ShowDialog();
// If the filename is empty the user took no picture
if (string.IsNullOrEmpty(dialog.FileName))
return null;
// (!) The OutOfMemoryException is thrown here (!)
var bitmap = new Bitmap(dialog.FileName);
File.Delete(dialog.FileName);
return bitmap;
}
该函数由事件处理程序调用：
private void _pictureBox_Click(object sender,EventArgs e)
{
_takePictureLinkLabel.Visible = false;
var image = Camera.TakePicture();
if (image == null)
return;
image = Camera.CutBitmap(image,2.5);
_pictureBox.Image = image;
_image = Camera.ImagetoByteArray(image);
}
解决方法
同样地,你可能应该使用图像,但是再次：不确定我是否期望这是成败;值得一试,但……
public static Bitmap TakePicture()
{
string filename;
using(var dialog = new CameraCaptureDialog
{
Resolution = new Size(1600,StillQuality = CameraCaptureStillQuality.Default
}) {
dialog.ShowDialog();
filename = dialog.FileName;
}
// If the filename is empty the user took no picture
if (string.IsNullOrEmpty(filename))
return null;
// (!) The OutOfMemoryException is thrown here (!)
var bitmap = new Bitmap(filename);
File.Delete(filename);
return bitmap;
}
private void _pictureBox_Click(object sender,EventArgs e)
{
_takePictureLinkLabel.Visible = false;
using(var image = Camera.TakePicture()) {
if (image == null)
return;
image = Camera.CutBitmap(image,2.5);
_pictureBox.Image = image;
_image = Camera.ImagetoByteArray(image);
}
}
我也会对CutBitmap等有点谨慎,以确保尽快发布.
.NET陷阱之五：奇怪的OutOfMemoryException——大对象堆引起的问题与对策
我们在开发过程中曾经遇到过一个奇怪的问题：当软件加载了很多比较大规模的数据后，会偶尔出现OutOfMemoryException异常，但通过内存检查工具却发现还有很多可用内存。于是我们怀疑是可用内存总量充足，但却没有足够的连续内存了——也就是说存在很多未分配的内存空隙。但不是说.NET运行时的垃圾收集器会压缩使用中的内存，从而使已经释放的内存空隙连成一片吗？于是我深入研究了一下垃圾回收相关的内容，最终明确的了问题所在——大对象堆（LOH）的使用。如果你也遇到过类似的问题或者对相关的细节有兴趣的话，就继续读读吧。
如果没有特殊说明，后面的叙述都是针对32位系统。
首先我们来探讨另外一个问题：不考虑非托管内存的使用，在最坏情况下，当系统出现OutOfMemoryException异常时，有效的内存（程序中有GC Root的对象所占用的内存）使用量会是多大呢？2G？ 1G？ 500M？ 50M？或者更小（是不是以为我在开玩笑）？来看下面这段代码（参考 https://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/）。
1 public class Program
2 {
3 static void Main(string[] args)
4 {
5 var smallBlockSize = 90000;
6 var largeBlockSize = 1 << 24;
7 var count = 0;
8 var bigBlock = new byte[0];
9 try
10 {
11 var smallBlocks = new List<byte[]>();
12 while (true)
13 {
14 GC.Collect();
15 bigBlock = new byte[largeBlockSize];
16 largeBlockSize++;
17 smallBlocks.Add(new byte[smallBlockSize]);
18 count++;
19 }
20 }
21 catch (OutOfMemoryException)
22 {
23 bigBlock = null;
24 GC.Collect();
25 Console.WriteLine("{0} Mb allocated",
26 (count * smallBlockSize) / (1024 * 1024));
27 }
28
29 Console.ReadLine();
30 }
31 }
这段代码不断的交替分配一个较小的数组和一个较大的数组，其中较小数组的大小为90, 000字节，而较大数组的大小从16M字节开始，每次增加一个字节。如代码第15行所示，在每一次循环中bigBlock都会引用新分配的大数组，从而使之前的大数组变成可以被垃圾回收的对象。在发生OutOfMemoryException时，实际上代码会有count个小数组和一个大小为 16M + count 的大数组处于有效状态。最后代码输出了异常发生时小数组所占用的内存总量。
下面是在我的机器上的运行结果——和你的预测有多大差别？提醒一下，如果你要亲自测试这段代码，而你的机器是64位的话，一定要把生成目标改为x86。
23 Mb allocated
考虑到32位程序有2G的可用内存，这里实现的使用率只有1%！
下面即介绍个中原因。需要说明的是，我只是想以最简单的方式阐明问题，所以有些语言可能并不精确，可以参考http://msdn.microsoft.com/en-us/magazine/cc534993.aspx以获得更详细的说明。
.NET的垃圾回收机制基于“Generation”的概念，并且一共有G0, G1, G2三个Generation。一般情况下，每个新创建的对象都属于于G0，对象每经历一次垃圾回收过程而未被回收时，就会进入下一个Generation（G0 -> G1 -> G2），但如果对象已经处于G2，则它仍然会处于G2中。
软件开始运行时，运行时会为每一个Generation预留一块连续的内存（这样说并不严格，但不影响此问题的描述），同时会保持一个指向此内存区域中尚未使用部分的指针P，当需要为对象分配空间时，直接返回P所在的地址，并将P做相应的调整即可，如下图所示。【顺便说一句，也正是因为这一技术，在.NET中创建一个对象要比在C或C++的堆中创建对象要快很多——当然，是在后者不使用额外的内存管理模块的情况下。】
在对某个Generation进行垃圾回收时，运行时会先标记所有可以从有效引用到达的对象，然后压缩内存空间，将有效对象集中到一起，而合并已回收的对象占用的空间，如下图所示。
但是，问题就出在上面特别标出的“一般情况”之外。.NET会将对象分成两种情况区别对象，一种是大小小于85, 000字节的对象，称之为小对象，它就对应于前面描述的一般情况；另外一种是大小在85, 000之上的对象，称之为大对象，就是它造成了前面示例代码中内存使用率的问题。在.NET中，所有大对象都是分配在另外一个特别的连续内存（LOH, Large Object Heap）中的，而且，每个大对象在创建时即属于G2，也就是说只有在进行Generation 2的垃圾回收时，才会处理LOH。而且在对LOH进行垃圾回收时不会压缩内存！更进一步，LOH上空间的使用方式也很特殊——当分配一个大对象时，运行时会优先尝试在LOH的尾部进行分配，如果尾部空间不足，就会尝试向操作系统请求更多的内存空间，只有在这一步也失败时，才会重新搜索之前无效对象留下的内存空隙。如下图所示：
从上到下看
- LOH中已经存在一个大小为85K的对象和一个大小为16M对象，当需要分配另外一个大小为85K的对象时，会在尾部分配空间；
- 此时发生了一次垃圾回收，大小为16M的对象被回收，其占用的空间为未使用状态，但运行时并没有对LOH进行压缩；
- 此时再分配一个大小为16.1M的对象时，分尝试在LOH尾部分配，但尾部空间不足。所以，
- 运行时向操作系统请求额外的内存，并将对象分配在尾部；
- 此时如果再需要分配一个大小为85K的对象，则优先使用尾部的空间。
所以前面的示例代码会造成LOH变成下面这个样子，当最后要分配16M + N的内存时，因为前面已经没有任何一块连续区域满足要求时，所以就会引发OutOfMemoryExceptiojn异常。
要解决这一问题其实并不容易，但可以考虑下面的策略。
- 将比较大的对象分割成较小的对象，使每个小对象大小小于85, 000字节，从而不再分配在LOH上；
- 尽量“重用”少量的大对象，而不是分配很多大对象；
- 每隔一段时间就重启一下程序。
最终我们发现，我们的软件中使用数组（List<float>）保存了一些曲线数据，而这些曲线的大小很可能会超过了85, 000字节，同时曲线对象的个数也非常多，从而对LOH造成了很大的压力，甚至出现了文章开头所描述的情况。针对这一情况，我们采用了策略1的方法，定义了一个类似C++中deque的数据结构，它以分块内存的方式存储数据，而且保证每一块的大小都小于85, 000，从而解决了这一问题。
此外要说的是，不要以为64位环境中可以忽略这一问题。虽然64位环境下有更大的内存空间，但对于操作系统来说，.NET中的LOH会提交很大范围的内存区域，所以当存在大量的内存空隙时，即使不会出现OutOfMemoryException异常，也会使得内页页面交换的频率不断上升，从而使软件运行的越来越慢。
最后分享我们定义的分块列表，它对IList<T>接口的实现行为与List<T>相同，代码中只给出了比较重要的几个方法。
1 public class BlockList<T> : IList<T>
2 {
3 private static int maxAllocSize;
4 private static int initAllocSize;
5 private T[][] blocks;
6 private int blockCount;
7 private int[] blockSizes;
8 private int version;
9 private int countCache;
10 private int countCacheVersion;
11
12 static BlockList()
13 {
14 var type = typeof(T);
15 var size = type.IsValueType ? Marshal.SizeOf(default(T)) : IntPtr.Size;
16 maxAllocSize = 80000 / size;
17 initAllocSize = 8;
18 }
19
20 public BlockList()
21 {
22 blocks = new T[8][];
23 blockSizes = new int[8];
24 blockCount = 0;
25 }
26
27 public void Add(T item)
28 {
29 int blockId = 0, blockSize = 0;
30 if (blockCount == 0)
31 {
32 UseNewBlock();
33 }
34 else
35 {
36 blockId = blockCount - 1;
37 blockSize = blockSizes[blockId];
38 if (blockSize == blocks[blockId].Length)
39 {
40 if (!ExpandBlock(blockId))
41 {
42 UseNewBlock();
43 ++blockId;
44 blockSize = 0;
45 }
46 }
47 }
48
49 blocks[blockId][blockSize] = item;
50 ++blockSizes[blockId];
51 ++version;
52 }
53
54 public void Insert(int index, T item)
55 {
56 if (index > Count)
57 {
58 throw new ArgumentOutOfRangeException("index");
59 }
60
61 if (blockCount == 0)
62 {
63 UseNewBlock();
64 blocks[0][0] = item;
65 blockSizes[0] = 1;
66 ++version;
67 return;
68 }
69
70 for (int i = 0; i < blockCount; ++i)
71 {
72 if (index >= blockSizes[i])
73 {
74 index -= blockSizes[i];
75 continue;
76 }
77
78 if (blockSizes[i] < blocks[i].Length || ExpandBlock(i))
79 {
80 for (var j = blockSizes[i]; j > index; --j)
81 {
82 blocks[i][j] = blocks[i][j - 1];
83 }
84
85 blocks[i][index] = item;
86 ++blockSizes[i];
87 break;
88 }
89
90 if (i == blockCount - 1)
91 {
92 UseNewBlock();
93 }
94
95 if (blockSizes[i + 1] == blocks[i + 1].Length
96 && !ExpandBlock(i + 1))
97 {
98 UseNewBlock();
99 var newBlock = blocks[blockCount - 1];
100 for (int j = blockCount - 1; j > i + 1; --j)
101 {
102 blocks[j] = blocks[j - 1];
103 blockSizes[j] = blockSizes[j - 1];
104 }
105
106 blocks[i + 1] = newBlock;
107 blockSizes[i + 1] = 0;
108 }
109
110 var nextBlock = blocks[i + 1];
111 var nextBlockSize = blockSizes[i + 1];
112 for (var j = nextBlockSize; j > 0; --j)
113 {
114 nextBlock[j] = nextBlock[j - 1];
115 }
116
117 nextBlock[0] = blocks[i][blockSizes[i] - 1];
118 ++blockSizes[i + 1];
119
120 for (var j = blockSizes[i] - 1; j > index; --j)
121 {
122 blocks[i][j] = blocks[i][j - 1];
123 }
124
125 blocks[i][index] = item;
126 break;
127 }
128
129 ++version;
130 }
131
132 public void RemoveAt(int index)
133 {
134 if (index < 0 || index >= Count)
135 {
136 throw new ArgumentOutOfRangeException("index");
137 }
138
139 for (int i = 0; i < blockCount; ++i)
140 {
141 if (index >= blockSizes[i])
142 {
143 index -= blockSizes[i];
144 continue;
145 }
146
147 if (blockSizes[i] == 1)
148 {
149 for (int j = i + 1; j < blockCount; ++j)
150 {
151 blocks[j - 1] = blocks[j];
152 blockSizes[j - 1] = blockSizes[j];
153 }
154
155 blocks[blockCount - 1] = null;
156 blockSizes[blockCount - 1] = 0;
157 --blockCount;
158 }
159 else
160 {
161 for (int j = index + 1; j < blockSizes[i]; ++j)
162 {
163 blocks[i][j - 1] = blocks[i][j];
164 }
165
166 blocks[i][blockSizes[i] - 1] = default(T);
167 --blockSizes[i];
168 }
169
170 break;
171 }
172
173 ++version;
174 }
175
176 private bool ExpandBlock(int blockId)
177 {
178 var length = blocks[blockId].Length;
179 if (length == maxAllocSize)
180 {
181 return false;
182 }
183
184 length = Math.Min(length * 2, maxAllocSize);
185 Array.Resize(ref blocks[blockId], length);
186 return true;
187 }
188
189 private void UseNewBlock()
190 {
191 if (blockCount == blocks.Length)
192 {
193 Array.Resize(ref blocks, blockCount * 2);
194 Array.Resize(ref blockSizes, blockCount * 2);
195 }
196
197 blocks[blockCount] = new T[initAllocSize];
198 blockSizes[blockCount] = 0;
199 ++blockCount;
200 }
201 }本文分享 CSDN - 唯笑志在。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
关于Windows – IIS7.5应用程序池回收 – .Net OutOfMemoryException和iis应用程序池回收作用的介绍已经告一段落，感谢您的耐心阅读，如果想了解更多关于"System.OutOfMemoryException" exception when you execute a query in SQL Server Manageme...、.net – 创建数组时的SystemOutOfMemoryException、.net – 移动设备上的OutOfMemoryException、.NET陷阱之五：奇怪的OutOfMemoryException——大对象堆引起的问题与对策的相关信息，请在本站寻找。
本文标签：
![[转帖]Ubuntu 安装 Wine方法（ubuntu如何安装wine）](https://www.gvkun.com/zb_users/cache/thumbs/4c83df0e2303284d68480d1b1378581d-180-120-1.jpg)
