cmsearch needs 3814.70 MB

[nico]

Firstly, wrap malloc/free, use one of the existing profiling memory managers or use system dependent code to determine memory used.

Is there any stable, simple to apply and free (open source) memory manager available? We don't have much resources (time and people) so any help is appreciated.

We are also working on a (in our eyes) even better solution: Running all WUs inside of a VM controlled by BOINC. At the moment however, we are far from starting first tests.

[Ananas]

Several allocs have already been wrapped (ESL_ALLOC/ESL_RALLOC) but that's not a profiling macro of course, not even one to find leaks.

I'm not sure what a memory manager would help us - I'm aware that the memory handling is not ideal but that's in sources that we do not control - and there isn't something like a few alloc calls that each ask for a big chunk, it's more like 20000 out of which very few calls ask for a lot and tons of functions asking for a few bytes/words/dwords of RAM (dynamic!) - and that is all hidden in a fairly deep call tree.

Problem is, that we did not make that program, we just adapted it to the project. Michael sure does have some influence, but we would need to come up with details about improvements and that is not so easy without knowing the internals of most functions.

[Michael H.W. Weber]

@fractal: So, the bottom line is that we have not only done all we can possibly do about the RAM problem, we even have managed to convince the developers of implementing a RAM forecast function in a future version for which we have supplied detailed information (as we have for other code improvements as e.g. for computational speed-up as well).

For now, we have suspended the really big CMS WUs since we are currently working on a fix that is different from all suggestions made before and should solve the RAM problem once forever. Meanwhile another important project from our long list is now running that should not pose any issues.

Michael.