Here’s a problem with what should be a continuously-running, unattended console app: I’m seeing too-frequent app exits from System.OutOfMemoryException being thrown from a wide variety of methods deep in the call stack — often System.String.ToCharArray(), or System.String.CtorCharArrayStartLength(), or System.Xml.XmlTextReaderImpl.InitTextReaderInput(), but sometimes down in a System.String.Concat() call in a MongoCollection.Save() call’s stack, and other unlikely places.
For what it’s worth, we’re using parallel tasks, but this is essentially the only app running on the server, and the app’s total thread count never gets over 60. In some of these cases I know of a reason for some other exception to be thrown, but OutOfMemoryException makes no sense in these contexts, and it creates problems:
- According to TaskManager and Perfmon logs, the system has had a minimum of 65% out of 8GB free memory when this has happened, and
- While exception handlers sometimes fire & log the exception, they do not prevent an app crash, and
- There’s no continuing from this exception without user interaction (unless you suppress windows error reporting, which isn’t what we want system-wide, or run the app as a service, which is possible but sub-optimal for our use-case)
So I’m aware of the workarounds mentioned above, but what I’d really like is some explanation — and ideally a code-based handler — for the unexpected OOM exceptions, so that we can engage appropriate continuation logic. Any ideas?
Getting that exception when using under 3GB of memory suggests that you are running a 32-bit app. Build it as a 64-bit app and it will be able to use as much memory as is available (close to 8GB).
As to why it’s failing in the first place…how large is the data are you working with? If it’s not very large, have you looked for references to data being kept around much longer than they are necessary (i.e. a memory leak), thus preventing proper GC?