dotnet performance:
Hi to all, I am getting this System.OutOfMemoryException calling the Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(<stream>,<Obj>) method. The type of <stream> is IO.MemoryStream =====Exception: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. at System.IO.MemoryStream.set_Capacity(Int32 value) at System.IO.MemoryStream.EnsureCapacity(Int32 value) at System.IO.MemoryStream.Write(Byte[] buffer, Int32 offset, Int32 count) at System.IO.BinaryWriter.Write(Double value) at System.Runtime.Serialization.Formatters.Binary.__BinaryWriter.WriteValue(I nternalPrimitiveTypeE code, Object value) at System.Runtime.Serialization.Formatters.Binary.__BinaryWriter.WriteMember( NameInfo memberNameInfo, NameInfo typeNameInfo, Object value) at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteKnownValu eClass(NameInfo memberNameInfo, NameInfo typeNameInfo, Object data) at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteMembers(N ameInfo memberNameInfo, NameInfo memberTypeNameInfo, Object memberData, WriteObj ectInfo objectInfo, NameInfo typeNameInfo, WriteObjectInfo memberObjectInfo) at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.WriteMemberSet up(WriteObjectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo, S tring memberName, Type memberType, Object memberData, WriteObjectInfo memberObje ctInfo) at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObj ectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo, String[] mem berNames, Type[] memberTypes, Object[] memberData, WriteObjectInfo[] memberObjec tInfos) at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Write(WriteObj ectInfo objectInfo, NameInfo memberNameInfo, NameInfo typeNameInfo) at System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Obje ct graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(S tream serializationStream, Object graph, Header[] headers, Boolean fCheck) at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(S tream serializationStream, Object graph) at SerializationBenchmark.Module1.Main() in C:\Develop\Projects\Visual Studio 2005\SerializationBenchmark\SerializationBenchmark\Module1.vb:line 41 ============= After building a benchmark application to reproduce the error (building progressively larger objects to serialize until getting the error). To understand the problem, I collected the following informations: Serialization stream lenght (before exception is thrown) 16,777,214 Bytes Allocated memory 1,028,914,416 Bytes [to get the memory I called GC.GetTotalMemory(False)] Please note my system is a x64 workstation with 6 GB RAM (and Windows Server 2003 R2 SP2 Enterprise). When the exception was thrown the total load of the system was about 4162 MB. The application configuration targets specifically x86 platform. Can anybody explain me this behaviour and how to workaround it? I cannot understand the why of the exception, since the lenght of the stream is lower than the Int32.MaxValue and I still have free RAM. Any help will be appreciated.
[quoted text, click to view] > After building a benchmark application to reproduce the error (building > progressively larger objects to serialize until getting the error). > To understand the problem, I collected the following informations: > Serialization stream lenght (before exception is thrown) 16,777,214 Bytes > Allocated memory 1,028,914,416 Bytes > [to get the memory I called GC.GetTotalMemory(False)] > > Please note my system is a x64 workstation with 6 GB RAM (and Windows > Server > 2003 R2 SP2 Enterprise). When the exception was thrown the total load of > the > system was about 4162 MB. > > The application configuration targets specifically x86 platform. > > Can anybody explain me this behaviour and how to workaround it? I cannot > understand the why of the exception, since the lenght of the stream is > lower > than the Int32.MaxValue and I still have free RAM.
Processes can use at most 2gb in 32 bit. I think your problem is memory fragmentation. Probably easiest to serialize chunks of the stream..
Hi Robert, Thank you very much for your reply. I agree that serializing smaller chunks should be the easiest way to work around it, but can I ask: 1- targeting my project to x64 platforms could solve the issue? (or at least move up the 2GB memory limit)? 2- How can I handle memory fragmentation? Thank you very much. [quoted text, click to view] "Robert" wrote: > > After building a benchmark application to reproduce the error (building > > progressively larger objects to serialize until getting the error). > > To understand the problem, I collected the following informations: > > Serialization stream lenght (before exception is thrown) 16,777,214 Bytes > > Allocated memory 1,028,914,416 Bytes > > [to get the memory I called GC.GetTotalMemory(False)] > > > > Please note my system is a x64 workstation with 6 GB RAM (and Windows > > Server > > 2003 R2 SP2 Enterprise). When the exception was thrown the total load of > > the > > system was about 4162 MB. > > > > The application configuration targets specifically x86 platform. > > > > Can anybody explain me this behaviour and how to workaround it? I cannot > > understand the why of the exception, since the lenght of the stream is > > lower > > than the Int32.MaxValue and I still have free RAM. > > > Processes can use at most 2gb in 32 bit. > > I think your problem is memory fragmentation. > > Probably easiest to serialize chunks of the stream.. > >
[quoted text, click to view] > I agree that serializing smaller chunks should be the easiest way to work > around it, but can I ask: > > 1- targeting my project to x64 platforms could solve the issue? (or at > least > move up the 2GB memory limit)? > 2- How can I handle memory fragmentation?
x64 should solve both problems. To minimize fragmentation, reuse memory as much as possible. Declare large arrays at the module level and do not destroy them. If you google for ".Net Memory Fragmentation" you will find many interesting links. Good luck. All of these issues are several levels down the tool chain from your code. So you are always fighting the "normal" way of doing things.
Thank you very much for your reply. [quoted text, click to view] > x64 should solve both problems.
Very True! After compiling my "benchmark application" in native x64, I found a very satisfactory memory management and have been able to allocate more then 4 GB in my process (and the test is still running without getting any OOM exception). I also tried to solve the problem for the 32 bit version by setting the /3GB switch at startup, but this was absolutely unsuccessfull. [quoted text, click to view] > If you google for ".Net Memory Fragmentation" you will find many interesting > links. > > Good luck. All of these issues are several levels down the tool chain from > your code. > So you are always fighting the "normal" way of doing things. >
I found interesting links, but - at the end - I'm choosing to change a bit the serialization procedure to serialize smaller chunks to avoid spending too much time in "fighting the "normal" way of doing things.", even because I cannot set a 64 bit system as requirement for the software. Thank you again for your very useful replies.
Don't see what you're looking for? Try a search.
|