Graphics.DrawImage OutOFMemory Exception
I'm getting an OutOfMemory
Exception when trying to resize larger images. Our server can only resize images of less then 1000x1000 pixels. My development machine seems too handle any size, and other developer machines seem to have the same limitations as the server. My development machine is also the best spec'd.
I feel like this code properly disposes of all the objects, but i could be wrong. I've tried using perfmon to view the .Net CLR memory but I'm unsure of how to interpret the results.
I'm stuck as to how to best solve this problem and get a definitive answer on why the problem exists. Any debugging ideas would be greatly appreciated.
Edit: Error occurs on g.DrawImage
using(Image imgToResize = Image.FromFile(path))
{
using (Bitmap b = new Bitmap(ResizeWidth, ResizeHeight, PixelFormat.Format24bppRgb))
{
using(Graphics g = Graphics.FromImage(b))
{
g.InterpolationMode = InterpolationMode.HighQualityBicubic;
g.DrawImage(imgToResize, 0, 0, ResizeWidth, ResizeHeight);
b.Save(DiskPathThumb(maxSize), ImageFormat.Jpeg);
}
}
}
开发者_运维知识库
Can you screenshot counters for PrivateBytes, LOH size, #Gen 2 collections?
What type of application is this? How deep is this into your application code? How many objects do you have on the LOH? Since the buffer that is being returned definitely qualifies as a Large Object. Have you looked at the call stack, the state of the heap, and fragmentation when this call fires?
FWIW, you might try the same code in a C or C++ version that uses the GDI. Every one of the graphics related functions you are using is a wrapper around the GDI and testing that in a test application on the failing machines would help narrow things down to the .Net Framework and not something else.
I was not able to get an OOM Exception, but the largest value I could pass was around 19866x19866 before the function would throw an InvalidParameterException. This is on a 64bit Win7 targeting .Net 4 w/VS2010.
Turns out this was somehow related to us using the SessionPageStatePersister
this was causing our gen2
stack to rise steadily over time and at some point before the app pool was recycled our systems wasn't able to handle much at all.
We have since reverted to the standard hidden field view state and this error has vanished.
精彩评论