Jari Juslin wrote: > Jari Juslin wrote: > >> Further question: In general situation, does this really correct >> problems or just hide them? > > > > Ok, I was a bit hasty once again. By reading the mailing list archive > and code I came to this asumption: if I want to run Kannel under heavy > load, I need to increase MAX_TAB_SIZE in gwlib/gwmem-check.c > significantly. If I still run to these panics, there is propably some > bad memory leak that should be hunted down. > > So, panic to "Too many concurrent allocations" can happen if a) Kannel > just has so high load, that is needs huge amounts of memory or b) if > Kannel leaks too much memory. Am I right? > > The last version of Kannel I have run without it reportin non-freed > areas on exit was 1.1.5.. I think I should do some memory leak > investigation and get back to you, if I fail to repair them myself. > > > I think you are correct in all assumptions. I increased the table size to 20 MB for our production systems (yes - we are running checking malloc in production), and we don't have any memory allocation panics. we do have memry leaks in some modules, but not serious enough to warrant a high ranking in the todo list.
-- Oded
