This project is read-only.

Out of Memory on zip file Save()

Aug 26, 2010 at 7:25 AM
Edited Aug 26, 2010 at 8:57 AM

I've read the other items related to out of memory errors on save that are related to memory streams (such as 67797), but I think my issue is different as I am using files, not memory streams. The error is intermittent and our application is deployed as a Citrix published application (that is, it runs in a virtualised environment).

A typical stack trace recorded in our error log is as follows:

20100825_15:09:15.187 (thread=1): Exception Message: Exception of type 'System.OutOfMemoryException' was thrown.
20100825_15:09:15.203 (thread=1): Exception Stack trace:
at Ionic.Zlib.ParallelDeflateOutputStream.WorkItem..ctor(Int32 size, CompressionLevel compressLevel, CompressionStrategy strategy)
at Ionic.Zlib.ParallelDeflateOutputStream._InitializePoolOfWorkItems()
at Ionic.Zlib.ParallelDeflateOutputStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at Ionic.Zlib.CrcCalculatorStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at Ionic.Zip.ZipEntry._WriteEntryData(Stream s)
at Ionic.Zip.ZipEntry.Write(Stream s)
at Ionic.Zip.ZipFile.Save()

Our code looks like this:

using (ZipFile zipFile = new ZipFile(zippedFilenameFullpath))
    foreach (string fileToZip in filesToZip)
        zipFile.AddFile(fileToZip, string.Empty);
    zipFile.Comment = commentDateTime.ToString(JBSConstants.STRING_ZIP_COMMENT_DATE_TEMPLATE);

We were using version but based on discussion item 80894 I have recently upgraded the application to and added code to set ParallelDeflatethreshold to -1 immediately after the object is constructed (just before the foreach statement) but it will take some time to get the software deployed into production and we haven't been able to reproduce the problem in our development and test environments - it only happens in production and only infrequently (we've not been able to 'make' it happen, only respond to issues when users are affected).

I'll update this issue if the problem is fixed by and the ParallelDeflatethreshold property, but I thought I'd raise it here in case there is anything that I've missed or anyone has ideas on other things to try.


Ben Robbins

Aug 6, 2011 at 3:11 PM

The out of memory condition on some large servers occurs because DotNetZip (in v1.9.1.5) tries to allocate too much memory on such machines. It scans for the number of CPUs on the server and allocates memory proportional to the number of CPUs.  While in principle this may sound benign (it did to me when I designed it) there is no upper limit on the memory consumption, and in practice it caused problems on servers where other applications were using the same resources. Hmm, you'd think I would have thought of that. Anyway the v1.9.1.7 release includes some more conservative logic in choosing the buffer sizes and the number of buffers, and should work better on larger machines. I'd love to get some direct feedback on that release.

just a note  - setting ParallelDeflateThreshold to -1 essentially turns off multi-threaded deflation .  This will affect the runtime performance of the deflater, but will not affect correctness.  So by doing it, you tell DotNetZip, "don't use multiple threads even when there might be a performance advantage to doing so".  It also implies "don't allocate memory buffers for those threads", which is why you can avoid the out-of-memory condition when you set the property to -1.  What I tried to do in v1.9.1.7 is be more conservative with memory usage so that no out-of-memory condition occurs, and therefore you do not need to explicitly turn off parallel deflation in order to avoid it.  (which means you get the perf benefit automatically) .

But as I said I am looking for feedback on the changes.

I know this is an old thread, but I thought I'd reply in case it's still an issue of interest to you, or to anyone else searching the archives.


Aug 8, 2011 at 7:55 AM

Thanks Cheeso. We've got a production release scheduled in the next few weeks so I'll try and sneak the version of DotNetZip into it, turn back on parallel deflate and see how it goes.



Oct 25, 2011 at 9:47 AM

I can confirm that the problem is fixed in version

Nov 7, 2011 at 5:16 PM

Great, thanks for the follow up.

Nov 24, 2011 at 8:25 AM

Hi Cheeso,

I struggled with something similar.

First all values were the default values and when I added a couple of directories (containing binary files) the save-command never returnes.

I found here a solution:

But what would be the best and fastest way to do this job?

I do not want to use a password and setting ParallelDeflate=-1 doen't look to be a good choice.

(I have downloaded v1.9.1.8)



Dec 9, 2011 at 6:06 AM

v1.9.1.8  OutOfMemoryException is thrown when saves a file with 6GB size in total.

System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at Ionic.Zip.ZipEntry.CopyThroughWithNoChange(Stream outstream)
   at Ionic.Zip.ZipEntry.CopyThroughOneEntry(Stream outStream)
   at Ionic.Zip.ZipEntry.Write(Stream s)
   at Ionic.Zip.ZipFile.Save()