CODEWITHSUNDEEP
c#.netperformance
Mehdi LAMRANI
Mehdi LAMRANI

Reputation: 11597

Control Memory-Hungy Multi-Threaded App

This a VERY open question.

Basically, I have a computing application that launches test combinations for N Scenarios.
Each test is conducted in a single dedicated thread, and involves reading large binary data, processing it, and dropping results to DB.

If the number of threads is too large, the app gets rogue and eats out all available memory and hangs out.. What is the most efficient way to exploit all CPU+RAM capabilities (High Performance computing i.e 12Cores/16GB RAM) without putting the system down to its knees (which happens if "too many" simultaneous threads are launched, "too many" being a relative notion of course)

I have to specify that I have a workers buffer queue with N workers, every time one finishes and dies a new one is launched via a Queue. This works pretty fine as of now. But I would like to avoid "manually" and "empirically" setting the number of simultaneous threads and have an intelligent scalable system that drops as many threads at a time that the system can properly handle, and stop at a "reasonable" memory usage (the target server is dedicated to the app so there is no problem regarding other applications except the system)

PS : I know that .Net 3.5 comes with Thread Pools and .Net 4 has interesting TPL capabilites, that I am still considering right now (I never went very deep into this so far).

PS 2 : After reading this post I was a bit puzzled by the "don't do this" answers. Though I think such request is fair for a memory-demanding computing program.

EDIT
After reading this post I will to try to use WMI features

Upvotes: 0

Views: 548

Answers (1)

usr
usr

Reputation: 171178

All built-in threading capabilities in .NET do not support adjusting according to memory usage. You need to build this yourself.

You can either predict memory usage or react to low memory conditions. Alternatives:

  1. Look at the amount of free memory on the system before launching a new task. If it is below 500mb, wait until enough has been freed.
  2. Launch tasks as they come and throttle as soon as some of them start to fail because of OOM. Restart them later. This alternative sucks big time because your process will do garbage collections like crazy to avoid the OOMs.

I recommend (1).

You can either look at free system memory or your own processes memory usage. In order to get the memory usage I recommend looking at private bytes using the Process class.

If you set aside 1GB of buffer on your 16GB system you run at 94% efficiency and are pretty safe.

Upvotes: 2

Related Questions