[sr-dev] A script function to get the reamining PKG MEM

[Iñaki Baz Castillo]

2010/4/16 Henning Westerholt <henning.westerholt at 1und1.de>:
> Hello Inaki,
>
> transaction live mainly in shared memory, so this could be another reason that
> the t_relay/ t_newtran fails

Yes sorry, my fault. Basically the problem would be the fact that the
worker has not enough memory to parse and create an error response.


>. But you're right, it should also fail due
> insufficient private memory .
>
>> So what I'm in mind is a new script function to get the current
>> available PKG mem, so the script can determine not to process the
>> request and reply (if it can) an error response. This would avoid the
>> creation of a new dialog, db queries and so on.
>
> There are already some functions that output mem status, albeit in the log.
> Take a look to pkg_status/shm_status() in cfgutils. So one could of course
> implement a PV that returns the number of available memory, or a function that
> checks for a certain range.

Thanks.


> But i wonder if this is really necessary. The last out of memory condition we
> observed in production is years away, if i remember correctly. So i'd suggest
> that you just use a proper size of PKG mem pool (like 10MB per process) and
> also enough shared memory, as RAM is really cheap this days. If then you still
> get a out of memory condition then there is a memory leak in the code, and
> this should just be fixed instead of trying to work around in the script here.

Yes, I agree. I experimented a PKG MEM issue (using 4 MB) last week
using Kamailio 1.5.1. Usually a worker in this server just consumes
191176 bytes (so far from 4 MB) so increasing the PKG MEM is not very
useful in this case as it would be reached soon (however using 1.5.4
I've not experimented this problem in 8 days with even more traffic).

But yes, you are fully right, if there is a memory leak it must be
fixed rather than doing a dirty workaround in the script :)


Thanks.

-- 
Iñaki Baz Castillo
<ibc at aliax.net>