Large Object Heap

Interesting Finds

Jason Haley — Wed, 19 Apr 2006 20:00:43 GMT

re: Large Object Heap

Anonymous — Wed, 19 Apr 2006 21:04:05 GMT

> the other reason is people usually don’t churn LOH too
> much – one typical pattern I’ve seen people use LOH is
> to allocate some large arrays that hold on to small
> objects.

What about DataTables? Large DataTable's allocates big continuous arrays for column values and there is no way to reuse one column array for another table, after disposing the first one.

Column of GUIDs or decimals can be allocated in LOH when DataTable contains about 5000 rows - not very much.

re: Large Object Heap

TAG — Wed, 19 Apr 2006 22:53:56 GMT

I've question - how 85000 was selected ? Any reasoning ?

re: Large Object Heap

maoni — Sat, 22 Apr 2006 01:12:36 GMT

Unfortunately I can't answer about DataTables - it's outside of my expertise.

85,000 bytes was selected based on tuning (running a bunch of scenarios of our own and from our partner teams).

re: Large Object Heap

Nomad — Thu, 04 May 2006 21:41:35 GMT

Maoni, It would be great if you look at my problem.. I've read all of your articles and it looks like that my trouble lies somewhere in memory defragmentation or something similar.
Look at url that I provided or contact me at gorbuz@gmail.com
PS. Sorry for my poor English, I'm from Ukraine

re: Large Object Heap

maoni — Thu, 11 May 2006 02:02:39 GMT

Nomad, I looked the link but I am not sure exactly how your issue is related to GC based on the info given. You didn't say if you were using workstation GC (with or without concurrent GC) or server GC. It should be easy to determine if the thread is a GC thread if you know what flavor you are using and by looking at the callstacks from those threads. There's no GC threads that are specifically for "memory defragmentation".

re: Large Object Heap

Nomad — Thu, 11 May 2006 15:45:37 GMT

Greetings. Thanks for response.
I'm using workstation GC now, but short test on server GC does not lead to that uncommon behaivor but just raised memory usage twice and up to OOM's. I'll test it again after RAM upgrade.
I've tried to collect stack traces using SysInternals Process Explorer (with windows debugging symbols, of course), but it looks like execution point for that thread changes every second and all of traces are just too different. Maybe we should use some other tools to get it?
I've found another strange thing - when I moved byte buffer operations (allocations, freeing, byte queue) to separate C++ assembly and done explicit memory allocation via Marshal::AllocHGlobal/ Marshal::FreeHGlobal (slower case) and c++ new/delete statements, server normal uptime (work time before "phantom thread" spawns) raised to 5-6hours, from 1-2 hours.

Just to explain why I've moved to explicit allocations I'll give you an example: there were 13649552 buffers allocated and 13648731 buffers released during 1h46m worktime. Each buffer is just a byte[] array of some size (less than 10k).
I asked myself, is that a normal workload for workstation GC? May be it just get flooded with such numbers? But perf. counters show only about 5-8% time in GC.. I've tried and got such result..

re: Large Object Heap

maoni — Fri, 12 May 2006 06:44:06 GMT

Nomad, try tuning concurrent GC off (look at my Using GC efficiently - part 2) - that way you can be sure there's no threads from GC (GC would be performed on your thread that triggered a GC).

re: Large Object Heap

Nomad — Fri, 12 May 2006 08:26:19 GMT

Ok, I set it up. I'll tell you of any results this evening (or morning in your time zone :))

re: Large Object Heap

Nomad — Sat, 13 May 2006 14:35:10 GMT

Behaivor with concurrent GC turned off changed significantly. First of all, server performance increased greatly - CPU usage shrinked in 1.5 times. For a few hours it worked perfectly, but after some time something strange happening - Gen 2 Heap raised to 450 MB, number of Gen 2 collections is increasing every second, % of time in GC is sliding between 5 and 80 percents.
When I read your "Using GC efficiently" just about a year ago, I began to tune my app's memory usage and always looked at performance monitor - I never had such high Gen 2 heap and collections and % time in GC always was <= 10%. It looks like there is hidden error (or a lot of errors) in my code that was not detected correctly with concurrent GC (except of strange thread).. I see, it's time to read your articles again and again :)

re: Large Object Heap

samfung2000 — Fri, 07 Jul 2006 19:35:38 GMT

GC collects base on 3 condictions:
1) Allocation exceeds the Gen0 threshold;

2) System.GC.Collect is called;

3) System is in low memory situation;

Can you please elaborate 1, What is the Gen0 threshold?
I thought when small object heap runs low GC would just allocate another Segment.

How responsive is 3?
My app has high memory usage in a single call and seems like GC is not collecting quick enough and therefore got an OufOfMemory exception.

Thanks.
PS this is good stuff.

re: Large Object Heap

maoni — Fri, 21 Jul 2006 00:51:06 GMT

samfung2000, if you search for either "budget" or "threshold" in my blog you will see explanation of it.

Re your question about your application getting OOM, you should verify that the objects are indeed dead. If you are sure of that please do feel free to contact our product support.

re: Large Object Heap

Ulf — Fri, 23 Mar 2007 18:38:48 GMT

Almost a year after the last :-)

One thing I am confused about is why double-objects are handled differently than other scalar types.

The limit for a double-array seems to be 8K instead of 85K (which has a very bad implication of the application I am working on).

This can be controlled by running this simple code:

static void Main(string[] args)

{

double[] array1 = new double[999];

Console.WriteLine(GC.GetGeneration(array1));

double[] array2 = new double[1000];

Console.WriteLine(GC.GetGeneration(array2));

}

The printout is:

I.e. the double-array with 1000 elements (8K) is immediately allocated to generation 2,in this case LOH.

To me this feels like a serous bug but are there anything smart here?

Regards

Ulf

LOH and doubles

OmegaMan — Mon, 02 Apr 2007 21:14:42 GMT

I reported this to Microsoft Connect and it now being considered a bug on the doubles issue.

See:

Large Object Heap (LOH) does not behave as expected for Double array placement

Link:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=266330

re: Large Object Heap

maoni — Tue, 15 May 2007 16:28:32 GMT

It's not a bug - we do this for performance reasons because doubles are accessed faster when they are aligned on a 8-byte boundary which large objects are.

Scalable Memory Usage in SQLCLR

SQLCLR Performance — Fri, 01 Jun 2007 20:56:58 GMT

There are few constraints on memory usage in SQLCLR modules. This freedom is one of the benefits of the

Why does the clone for double array of length 124 go to LOH

alps_xing — Tue, 25 Mar 2008 04:54:45 GMT

Hi, Maoni

I used below codes to do a LOH test, and found that when the double array length is larger-equal than 124, the clone operation will increase the LOH usage. However as we know, the LOH threshold for double array should be 999.

Does the clone operation do some boundary alignment? And why the threshold for Clone is 123?

As below, the length of the array is 124. The array1's generation is 0, and array2's generation is 2, which make the LOH churned.

If I change the array length to 123, the generation of array1 and array2 are both 0.

using System;

using System.Collections.Generic;

using System.Text;

namespace ConsoleApplication2

{

class Program

{

static void Main(string[] args)

{

while(true)

{

// If I change the size to 123, the LOH will not be churned.

double[] array1 = new double[124];

Console.WriteLine(GC.GetGeneration(array1));

double[] array2 = (double [])array1.Clone();

System.Threading.Thread.Sleep(1);

}

Thanks.

Xing Qianqian

25-Mar-2008

re: Large Object Heap

Jairo — Thu, 08 May 2008 22:31:55 GMT

What about the Cache? if I have a LOH in the Cache (maybe a DataSet), setting the Cache object to null is not allowed (an exception is thrown), just removing it would work?? (Cache.Remove("objectId")).

Thanks!!!

re: Large Object Heap

Shane — Sat, 03 Oct 2009 15:29:03 GMT

It would be nice if a lot of the .ToArray() function's could use recycled object's.