<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
<div class="moz-cite-prefix">On 16/06/15 14:43, smititelu wrote:<br>
</div>
<blockquote cite="mid:558019DB.10902@1and1.ro" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
Hello everyone,<br>
<br>
We are thinking of a way to debug per module memory consumption
(both private and shared). Something like a "kamctl fifo shmem<b>
</b><b>module_name</b>" to print how much memory has been alloc'ed
for that module and which function had alloc'ed. <br>
<br>
One of the solutions would be to make use of the shm_info() and
pkg_info(), call them at the beginning and at the end of a
function and do some subtraction at the end. Then correlate this
data with a per module stats which will be printed with "kamctl
stats <b>module_name</b>". This would be ok if one needs mem
stats only for some specific modules.<br>
</blockquote>
<br>
this would eventually work for pkg, but for shm is not a safe
approach, because in parallel, another process can
allocate/dealocate shm.<br>
<br>
Also, for shm, what is allocated inside a module can be dealocated
somewhere else (e.g., avps can be set by modules, but freed by core
or tm).<br>
<br>
<blockquote cite="mid:558019DB.10902@1and1.ro" type="cite"> <br>
Another solution would be to make use of the *_malloc stubs used
when MEM_DEBUG is enabled and keep the function name and size. Buf
it would be hard to count how much memory is alloc'ed by the
higher module function in scenarios when the actual allocations
are done in other modules (e.g. db_allocate_rows()).<br>
</blockquote>
<br>
Given the above, when some memory is allocated by a module and freed
by another component, perhaps this is the best approach (at least
the one coming in my mind right now). Trying to keep a counter per
module is not sufficient, as allocated size won't be decreased when
freeing is in another place.<br>
<blockquote cite="mid:558019DB.10902@1and1.ro" type="cite"> <br>
Also we have in mind that one would not want to compile kamailio
with MEM_DEBUG flag but still want to make use of the feature...<br>
<br>
If you think of some other solution or have some advices for this,
please comment.<br>
</blockquote>
This has to be done as add on to the memory manager via a module,
something similar to what rpc command pkg.stats does, using some
callbacks, to be sure it is not slowing down the core when this
feature is not wanted/enabled.<br>
<br>
Perhaps an array with the shm and pkg counters, updated on callbacks
for *malloc/*realloc/*free, still relying on module name stored in
the memory chunk structure at malloc time, in order to decrease it
properly at free time.<br>
<br>
To speed up, instead of module name, it can be stored an index
associated at startup with the module name to avoid string
comparisons.<br>
<br>
When coding the feature, it would be good to add it in between
#ifdef ... #endif to be able to do performance measurments and
disable it completely if has big impact. It has relevance for
profiling and would be useful to have, just to be sure is not
slowing down a lot.<br>
<br>
Cheers,<br>
Daniel<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Book: SIP Routing With Kamailio - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a></pre>
</body>
</html>