I am following up from this question here
The problem I have is that I have some large objects coming from an MSMQ mainly Strings. I have narrowed down my memory problems to these objects being created in the Large Object Heap (LOH) and therefore fragmenting it (confirmed that with some help from the profiler).
In the question I posted above I got some workarounds mainly in the form of splitting up the String into char arrays which I did.
The problem I am facing is that at the end of the string processing (in whatever form that is) I need to send that string to another system which I have no control over. So I was thinking of the following solution to have this String placed in the LOH:
Whatever I do - one way or another - the String will have to be complete (no char arrays or compressed).
Am I stuck here? I am thinking if using a managed environment was a mistake here and whether we should bite the bullet and go for a C++ kind of environment.
Thanks, Yannis
EDIT: I have narrowed down the problem to exactly the code posted here
The large string that comes through is placed in the LOH. I have removed every single processing module from point where i have received the message onwards and the memory consumption trend remains the same.
So I guess i need to change the way this WorkContext is passed around between systems.
If an object is greater than or equal to 85,000 bytes in size, it's considered a large object. This number was determined by performance tuning. When an object allocation request is for 85,000 or more bytes, the runtime allocates it on the large object heap.
The worst case scenario. The design of the Large Object Heap means that its' worse case will occur when the short-lived arrays are large and can vary in size a bit, and if the longer-lived arrays are small.
What are Pinned Object Heaps in C#? A dedicated Pinned Object Memory, a fairly new type of managed heap segment, was added to the GC in . NET 5. (we have Small and Large Object Heaps so far). Pinning comes with its own set of drawbacks, as it causes fragmentation, and complicates object compaction a lot.
Well your options depend on how the 3rd party system is receiving data. If you can stream to it somehow then you don't have to have it all in memory in one go. If that is the case then compressing (which will probably really help your network load if its easily compressible data) is great as you can decompress through a stream and punt it to the 3rd party system in chunks.
The same of course would work if you split your strings up to go below LoH threshold.
If not then I would still advocate splitting the payload on the MSMQ message, and then using a memory pool of prealloacted and reused byte arrays for the re-assembly before sending it to the client. Microsoft has an implementation you can use http://msdn.microsoft.com/en-us/library/system.servicemodel.channels.buffermanager.aspx
The final option I can think of, is to handle the msmq deserialisation in unmanaged code in C++ and create your own custom large block memory pool using placement new to deserialise the strings into that. You could keep it relatively simple by ensuring your pool buffers are sufficient for the longest message possible rather than trying to be clever and dynamic which is hard.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With