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@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users