Re: Forcing a Large Object Heap allocation.

From: Alvin Bruney [MVP] (vapor)
Date: 08/02/04

  • Next message: tristant: "Has anybody succesfully used VB.NET on Oracle on UNIX ?" 
    Date: Sun, 1 Aug 2004 23:13:42 -0500

    I'm confused by a couple of things in your response.

    > I am working on an app that MUST be responsive at all times. Our
    > application
    > has a very large managed memory footprint (> 1GB of small objects).
    How much memory is available on the machine? Bear in mind that .net
    allocates 2gigs of address space max. At that rate, with other apps running
    on the box, you should be passing the recommended 60% memory limit. Pass
    that point and you should be experiencing an unstable app IMO.

     We are
    > seeing that our app hangs for a couple of seconds when the garbage
    > collector
    > compacts the heap.
    GC works by copying live objects, with such extreme memory pressure as your
    app is placing on the system, 2 seconds is reasonable.

    > Pinning many small
    > objects in the regular heap causes poorer performance than allocating many
    > large objects in the LOH.
    What benefit do you see by pinning managed objects?

    > Is there any way to avoid the ~2 second pause caused by the compacting
    > process?

    I'd like to know why the app is so memory intensive before dishing out
    advice. Maybe you can go into some more detail about the application and the
    footprint size. I've never really seen such a demanding memory requirement
    for run of the mill type applications. 

    -- 
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27***
"Frank" <google@xemaps.com> wrote in message 
news:10gq8s591a6f86b@corp.supernews.com...
> Alvin,
>
> I am working on an app that MUST be responsive at all times. Our 
> application
> has a very large managed memory footprint (> 1GB of small objects). We are
> seeing that our app hangs for a couple of seconds when the garbage 
> collector
> compacts the heap. Since our app must remain responsive we would rather 
> take
> the hit of allocating on the LOH and avoid the "compacting" phase all
> together. The LOH has been described as being more similar to the C++ 
> heap,
> which is what we want. However, we want to try to avoid making calls into
> unmanaged code for all our allocations and deallocations. Pinning many 
> small
> objects in the regular heap causes poorer performance than allocating many
> large objects in the LOH.
>
> Is there any way to avoid the ~2 second pause caused by the compacting
> process?
>
> Thanks,
>
> Frank
>
> "Alvin Bruney [MVP]" <vapor at steaming post office> wrote in message
> news:OcGsK$9dEHA.1280@TK2MSFTNGP10.phx.gbl...
>> What's the reason for this? Large objects need to live on the large 
>> object
>> heap, small objects don't need to.
>>
>> -- 
>> Regards,
>> Alvin Bruney
>> [ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
>> Got tidbits? Get it here... http://tinyurl.com/27***
>> "Frank" <google@xemaps.com> wrote in message
>> news:10got60mls6p3ff@corp.supernews.com...
>> > Does anyone know if it is possible to force a small object to be
> allocated
>> > on the Large Object Heap (LOH)?
>> >
>> > Thanks,
>> > Frank
>> >
>> >
>>
>>
>
>
  • Next message: tristant: "Has anybody succesfully used VB.NET on Oracle on UNIX ?"
    Loading