6 Oct
2008
6 Oct
'08
8:44 p.m.
In that particular deployment I have POSTGRES as a db.
Here's the set of loaded modules:
loadmodule "postgres.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "uri.so"
loadmodule "dispatcher.so"
loadmodule "mi_fifo.so"
loadmodule "xlog.so"
loadmodule "textops.so"
loadmodule "avpops.so"
loadmodule "uac_redirect.so"
loadmodule "acc.so"
loadmodule "gflags.so"
loadmodule "exec.so"
Regards,
Ovidiu Sas
On Mon, Oct 6, 2008 at 1:09 PM, Henning Westerholt
<henning.westerholt(a)1und1.de> wrote:
On Monday 06 October 2008, Daniel-Constantin Mierla
wrote:
[..]
Hi Daniel,
yes, i also had this impression. If i understand the log correctly, then there
about 6400 not freed database results, that causes the out of memory
condition. This are about 1/5 to 1/4 of the total calls that lead to this
problem, not good. I checked the mysql driver functions in question, but i
did not found something yet. So i also suppose the problem is related to the
used modules. Ovidiu, how does this module set matches to the modules you
use?
Cheers,
Henning
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
no, the reason for reversion is that the latest
version running in
production will not show the problem because we adopted preventive
reset to minimize impact to customer calls. So I don't know yet if it
shows this problem or not.
So I collected the logs using a revision that I was sure could
recreate the problem.
OK, I understand now. I was looking at the logs and there seems to be a
leak with db operations - something does not free a db result. I will go
over the modules that you are using and try to spot any issue -- i will
check the change log to see if something happened in the last time
regarding such issue..
[..]