large-object-heap

What is the difference between large object heap and GC 3rd generation objects? The LOH (Large Object Heap) is a single heap where large objects are allocated directly and stay there until they are collected. Objects are directly allocated into the LOH based on their size e.g. being equal or greater than 85000 bytes. Generational objects are "small" objects that are allocated into the SOH (Small Object Heap) which is a single heap. Objects in the SOH have an associated generation which denotes how many collections they have survived up to the maximum generation e.g. 2. As the generation number

Recently with 4.5 .NET support, users can allocate more than 2 GB of memory for an object. In order to do that users can set the gcAllowVeryLargeObjects to true in the app.config file, and things would work fine. However I am having difficulty in finding this setting for ASP.NET. I have an web site for which I need to test if this is really supported in our web site. I know that the VS inbuilt server is a 32 bit process. So it users can't simply launch the website and test it for large arrays. Is this even possible with ASP.NET? I am using IIS7 to host my website. Acording to MSDN you can

I have a windows console app that is supposed to run without restarts for days and months. The app retrieves "work" from an MSMQ and process it. There are 30 threads that process a work chunk simultaneously. Each work chunk coming from the MSMQ is approximately 200kb most of which is allocated in a single String object. I have noticed that after processing about 3-4 thousands of these work chunks the memory consumption of the application is ridiculously high consuming 1 - 1.5 gb of memory. I run the app through a profiler and noticed that most of this memory (maybe a gig or so) is unused in

I have a C# 4.0 application (single producer/single consumer) which transfers huge amount of data in chunks. Although there's no new memory allocation I run out of memory after a while. I profiled memory using Redgate memory profiler and there are a lot of free memory there. It says free memory cannot be used because of fragmentation. I use a blocking collection as the buffer and byte arrays as the members: BlockingCollection<byte[]> segments = new BlockingCollection<byte[]>(8); // producer: segments.Add(buffer); // consumer: byte[] buffer = _segments.Take(); How can I avoid managed memory

This question is a follow up to Efficient way to transfer many binary files into SQL Server database I originally asked why using File.ReadAllBytes was causing rapid memory use and it was concluded using that method put the data on the large object heap which cannot be easily reclaimed during run-time. My question now is how to avoid that situation? using (var fs = new FileStream(path, FileMode.Open)) { using (var ms = new MemoryStream()) { byte[] buffer = new byte[2048]; int bytesRead; while ((bytesRead = fs.Read(buffer, 0, buffer.Length)) > 0) { ms.Write(buffer, 0, bytesRead); } return new

Our application continuously allocates arrays for large quantities of data (say tens to hundreds of megabytes) which live for a shortish amount of time before being discarded. Done naively this can cause large object heap fragmentation, eventually causing the application to crash with an OutOfMemoryException despite the size of the currently live objects not being excessive. One way we have successfully managed this in the past is to chunk up the arrays to ensure they don't end up on the LOH, the idea being to avoid fragmentation by allowing memory to be compacted by the garbage collector. Our

If you application is such that it has to do lot of allocation/de-allocation of large size objects (>85000 Bytes), its eventually will cause memory fragmentation and you application will throw an Out of memory exception. Is there any solution to this problem or is it a limitation of CLR memory management? Unfortunately, all the info I've ever seen only suggests managing risk factors yourself: reuse large objects, allocate them at the beginning, make sure they're of sizes that are multiples of each other, use alternative data structures (lists, trees) instead of arrays. That just gave me an