blocks|key|4675613|text|当垃圾收集器释放对象时，它不会自动释放内存，它会保留该内存以帮助最小化将来发生的错误锁的开销。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4675614|当内存不足的情况被触发时，内存将返回给操作系统，当您查看任务管理器时，您将看到更多可用内存。这通常发生在2+2GB标记左右，或者如果您使用relevant+switch，则为3+2GB。|offset|length|4675615|<contentious>|style|CODE|4675616|通过在对象死亡时将其设置为null，您可以鼓励GC重用这些对象所消耗的内存，这限制了不断增长的内存消耗。|4675617|但是您应该将哪些对象设置为null呢？大对象、大集合、频繁创建的对象。|4675618|</contentious>|4675619|编辑：有证据支持将对象的值设置为null。详细信息请参见this。当然，不需要来将对象设置为null，关键是它对内存管理有任何帮助吗？|BOLD|4675620|EDIT：如果存在这样的东西，我们需要一个最新的基准，而不是继续发表意见。|4675621|entityMap|0|LINK|mutability|MUTABLE|url|http://technet.microsoft.com/en-us/library/bb124810.aspx|1|http://weblogs.asp.net/pwilson/archive/2004/02/14/73033.aspx^0|0|1X|F|0|0|0|D|0|0|0|0|E|0|0|2|10|3|S|4|1|0|0|4|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@$D|16|E|17|1|18]]|A|$]]|$1|F|3|G|5|6|7|19|8|@$D|1A|E|1B|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1C|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1D|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1E|8|@$D|1F|E|1G|H|I]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1H|8|@$D|1I|E|1J|H|R]|$D|1K|E|1L|H|R]]|9|@$D|1M|E|1N|1|1O]]|A|$]]|$1|S|3|T|5|6|7|1P|8|@$D|1Q|E|1R|H|R]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]|12|$5|X|Y|Z|A|$10|13]]]]

The Garbage Collector doesn't automatically free memory when it releases objects, it holds on to that memory to help minimise the expense of future mallocs.

When a low memory condition is triggered that memory will be returned to the OS and you will see more available memory when looking through task manager. This will normally happen about the 2GB mark, or 3GB if you use the <a href="http://technet.microsoft.com/en-us/library/bb124810.aspx" rel="nofollow noreferrer">relevant switch</a>.

<code>&lt;contentious&gt;</code>

By setting objects to null when they are dead you can encourage the GC to reuse the memory consumed by those objects, this limiting the growing consumption of memory.

But which objects should you set to null? Big objects, large collections, frequently created objects.

<code>&lt;/contentious&gt;</code>

EDIT: There is evidence to support the value of setting objects to null. See <a href="http://weblogs.asp.net/pwilson/archive/2004/02/14/73033.aspx" rel="nofollow noreferrer">this</a> for detail. Of course there is no need to set objects to null, the point is does it help memory management in any way?

EDIT: We need a recent benchmark if such a thing exists rather than continuing to opine.

blocks|key|1041837|text|有没有可能你没有处理各种一次性的对象(特别是与数据库相关的)。这将留下它们，可能会占用大量的非托管资源，直到GC运行并调用它们的终结器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1041838|有必要针对您的进程运行perfmon，并查看一些关键资源(如句柄)是否有稳定的增长，或者您的DB提供程序是否公开性能计数器然后连接或打开结果集。|1041839|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Is it possible you are not disposing of various disposable objects (particular DB related). This would leave them around, potentially tying up large amounts of unmanaged resources until the GC runs and their finalizers are called.

It would be worth running perfmon against you process and looking to see if there is a steady growth in some critical resource, like handles, or if your DB provider exposes performance counters then connections or open result sets.

blocks|key|4675664|text|我同意edg回答的第一部分，但他说：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4675665|4675666|“通过在对象死亡时将其设置为null，您可以鼓励GC重用由这些对象消耗的内存，这限制了不断增长的内存消耗。”|blockquote|4675667|4675668|4675669|是不正确的。您永远不需要将对象设置为null，因为在对象超出作用域之后，GC最终会收集该对象。|4675670|这在SO上的回答中已经讨论过了：Setting+Objects+to+Null/Nothing+after+use+in+.NET|offset|length|4675671|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/2785/setting-objects-to-nullnothing-after-use-in-dot-net^0|0|0|0|0|0|0|G|1D|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|X|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|11|8|@]|9|@$L|12|M|13|1|14]]|A|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

I agree with the first part of edg's answer, but where he says:

<blockquote>
 "By setting objects to null when they
 are dead you can encourage the GC to
 reuse the memory consumed by those
 objects, this limiting the growing
 consumption of memory."
</blockquote>

is incorrect. You never need to set an object to null since the GC will eventually collect your object after it goes out of scope.

This was discussed in this answer on SO: <a href="https://stackoverflow.com/questions/2785/setting-objects-to-nullnothing-after-use-in-dot-net">Setting Objects to Null/Nothing after use in .NET</a>

blocks|key|892328|text|不要使用Arraylist(垃圾收集不能很好地使用它们)，使用泛型列表|type|unstyled|depth|inlineStyleRanges|entityRanges|data|892329|另一个常见的错误是在web.config+Debug=true中，这会消耗大量内存，将选项更改为"false“。|892330|要做的另一件事是使用CLRProfiler来跟踪问题。|892331|祝你好运，佩德罗|892332|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Don't user Arraylists (garbage collect don't work weel with them), use instead generic lists

Other common error is to have in web.config Debug=true, this consume lot of memory, change the option to "false".

Other thing to do is use CLRProfiler, to trace the problem.

Good Luck,
Pedro

blocks|key|892384|text|这听起来像是发生了内存泄漏，进程不断地泄漏内存，直到它因内存不足而崩溃，然后由服务器自动重新启动。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|892385|在地址空间耗尽之前，1.5+32大约是32位进程可以分配的最大内存量。|892386|需要寻找的东西：|892387|892388|你自己做缓存吗？何时从缓存中删除项?+Dispose是否存在于某个地方，数据每隔一段时间就会被添加到集合中，但从未被删除?Dispose你是否对实现IDisposable?|unordered-list-item|892389|Do的每个对象调用Dispose?你是否访问过任何非托管代码(COM对象或使用DllImport)或分配非托管内存(例如使用|892390|类)？分配到那里的任何东西都不会被垃圾收集器释放，你必须自己释放它。|892391|你使用第三方库或来自第三方的任何代码吗？它也可以包含列表中的任何问题。|892392|892393|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|U|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|X|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|Y|8|@]|9|@]|A|$]]|$1|N|3|O|5|I|7|Z|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

It sounds like you have a memory leak, the process keeps leaking memory until it crushes with an out-of-memory condition and is then automatically restarted by the server.

1.5GB is about the maximum amount of memory a 32 bit process can allocate before running out of address space.

Somethings to look for:

<ul>
<li>Do you do your own caching? when are items removed from the cache?</li>
<li>Is there somewhere data is added to a collection every once in a while but never removed?</li>
<li>Do you call Dispose on every object that implements IDisposable?</li>
<li>Do you access any non-managed code at all (COM objects or using DllImport) or allocate non-managed memory (using the Marshal class for example)? anything that is allocated there is never freed by the garbage collector, you have to free it yourself.</li>
<li>Do you use 3rd party libraries or any code from 3rd parties? it can have any of the problems in the list too.</li>
</ul>

blocks|key|3208079|text|确保你没有建立你的项目的调试版本。有一个特性*当你有一个调试构建时，如果你实例化任何包含事件定义的对象，即使你不引发事件，它也只会无限期地持有一小块内存。随着时间的推移，这些小的内存会吞噬你的内存池，直到它最终重启web进程，并重新启动。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3208080|*我称这是一个功能(而不是错误)，因为它从.Net+2(在.Net+1.1中不存在)开始就存在了，并且没有补丁来修复它。内存泄漏一定是由于调试时所需的某些功能造成的。|3208081|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Ensure that you aren't putting up a debug build of your project. There's a feature* that when you have a debug build, if you instantiate any object that contains the definition for an event, even if you don't raise the event, it will hold only a small piece of memory indefinitely. Over time, these small pieces of memory will eat away at your memory pool, until it eventually restarts the web process, and start again.

*I call this a feature (and not a bug) because it's been around since the beginning of .Net 2 (not present in .Net 1.1), and there's been no patch to fix it. The memory leak must be due to some feature needed when debugging.

blocks|key|1047882|text|我们遇到了类似的情况，并更改了所有数据库连接，以使用try/catch/finally方法。Try用于执行代码，捕获错误收集，最后关闭所有变量和数据库连接。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1047883|internal+BECollection<ReportEntity>+GetSomeReport()
++++{
++++++++Database+db+=+DatabaseFactory.CreateDatabase();
++++++++BECollection<ReportEntity>+_ind+=+new+BECollection<ReportEntity>();
++++++++System.Data.Common.DbCommand+dbc+=+db.GetStoredProcCommand("storedprocedure");

++++++++try
++++++++{
++++++++++++SqlDataReader+reader+=+(SqlDataReader)db.ExecuteReader(dbc);
++++++++++++while+(reader.Read())
++++++++++++{
++++++++++++++++//populate+entity
++++++++++++}
++++++++}
++++++++catch+(Exception+ex)
++++++++{
++++++++++++Logging.LogMe(ex.Message.ToString(),+"Error+on+SomeLayer/SomeReport",+1,+1);
++++++++++++return+null;
++++++++}
++++++++finally
++++++++{
++++++++++++dbc.Connection.Close();
++++++++++++_ind+=+null;
++++++++}
++++++++return+_ind;
++++}|code-block|syntax|javascript|1047884|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

We were having similar situations occur and altered all our database connections to use a try/catch/finally approach.
Try was used to execute code, catch for error collection, and finally to close all variables and database connections.

<pre><code>internal BECollection&lt;ReportEntity&gt; GetSomeReport()
 {
 Database db = DatabaseFactory.CreateDatabase();
 BECollection&lt;ReportEntity&gt; _ind = new BECollection&lt;ReportEntity&gt;();
 System.Data.Common.DbCommand dbc = db.GetStoredProcCommand("storedprocedure");

 try
 {
 SqlDataReader reader = (SqlDataReader)db.ExecuteReader(dbc);
 while (reader.Read())
 {
 //populate entity
 }
 }
 catch (Exception ex)
 {
 Logging.LogMe(ex.Message.ToString(), "Error on SomeLayer/SomeReport", 1, 1);
 return null;
 }
 finally
 {
 dbc.Connection.Close();
 _ind = null;
 }
 return _ind;
 }
</code></pre>

blocks|key|4675780|text|我的第一个猜测是内存泄漏。我的第二个猜测是，这是正常行为--只有当你遇到严重的内存压力时，GC才会被触发。唯一确定的方法是结合使用分析器和PerfMon之类的工具。一些站点：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4675781|4675782|http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx|unordered-list-item|offset|length|4675783|http://support.microsoft.com/kb/318263|4675784|Tess's+excellent+lab+series|4675785|4675786|另外，我要确保你不是在调试模式下运行(如前所述)。|4675787|至于HTTP错误-假设您在服务器GC模式下运行，它会尽其所能不阻止请求。找出这些HTTP错误是很有趣的--从我过去看到的情况来看，这不是正常的行为，可能会指出问题的更多根源。|4675788|entityMap|0|LINK|mutability|MUTABLE|url|1|2|http://blogs.msdn.com/tess/pages/net-debugging-demos-information-and-setup-instructions.aspx^0|0|0|0|1M|0|0|0|12|1|0|0|R|2|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|12|8|@]|9|@$F|13|G|14|1|15]]|A|$]]|$1|H|3|I|5|E|7|16|8|@]|9|@$F|17|G|18|1|19]]|A|$]]|$1|J|3|K|5|E|7|1A|8|@]|9|@$F|1B|G|1C|1|1D]]|A|$]]|$1|L|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1F|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1H|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|D]]|X|$5|T|U|V|A|$W|I]]|Y|$5|T|U|V|A|$W|Z]]]]

My first guess would be a memory leak. My second guess would be that it is normal behavior - the GC won't be fired until you have significant memory pressure. The only way to be sure is to use a combination of a profiler and things like PerfMon. Some sites:

<ul>
<li><a href="http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx" rel="nofollow noreferrer"><a href="http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx" rel="nofollow noreferrer">http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx</a></a></li>
<li><a href="http://support.microsoft.com/kb/318263" rel="nofollow noreferrer"><a href="http://support.microsoft.com/kb/318263" rel="nofollow noreferrer">http://support.microsoft.com/kb/318263</a></a></li>
<li><a href="http://blogs.msdn.com/tess/pages/net-debugging-demos-information-and-setup-instructions.aspx" rel="nofollow noreferrer">Tess's excellent lab series</a></li>
</ul>

In addition I would make sure you aren't running in Debug mode (as already mentioned). 

As far as the HTTP errors - assuming you are running in server GC mode, it tries to do everything it can to not block requests. It would be interesting to find out what those HTTP errors are - that's not normal behavior from what I've seen in the past, and might point to some more of the root of your issue.

My huge 32-bit web services LLBLGen-based data access application is running alone on a dedicated 64-bit machine. Its physical memory consumption steadily grows up to approximately 2GB when the process releases almost all of the allocated space (up to 1,5GB) and continues to grow from that point again. There is no observable increase in Page Input values or other page file usage parameters so it looks like the memory is released rather than being swapped out to page file. I am thinking what kind of profile is this? There is nothing to actually prevent the process from grabbing all memory it can, on the other hand there are unacceptable http internal errors around the memory release - probably the clean-up blocks useful work. What would be a good strategy to make the cleanup less obtrusive, given the above is an acceptable behaviour in the first place.

Too much physical memory for an asp.net app?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我的基于LLBLGen的大型32位web服务数据访问应用程序在一台专用的64位计算机上单独运行。当进程释放几乎所有分配的空间(最多1，5 2GB )时，它的物理内存消耗稳定地增长到大约2 2GB，并从这一点开始继续增长。页面输入值或其他页面文件使用参数没有明显增加，因此看起来内存被释放了，而不是换出到页面文件。我在想这...

问对于asp.net应用程序来说，物理内存太大了？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问对于asp.net应用程序来说，物理内存太大了？EN