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:
[..]
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..
[..]
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
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org