2010/4/16 Henning Westerholt henning.westerholt@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.