Hi, Thanks, now i will investigate further. I almost gave up searching for specific calls because i was suspecting a configuration/usage issue. But you are probably right i have to dig deeper.
I have not tried master branch yet (production system) but i am now trying to replicate the problem by routing a few calls over a test-instance so i can narrow down the problem hopefully. Best Regards Max M. On 02/21/2014 05:11 PM, Stefan Sayer wrote: > Max, > > o Max Mühlbronner on 02/21/2014 01:32 PM: >> Hi list, >> >> I think i have already reported the issue i came across on 1.5.0 but on >> 1.5.1 also. I see a lot of sems threads (checking with ps -eLf) but many >> of the threads are never stopped/destroyed correctly. >> >> Over time the number grows so at some point there are hundreds/thousands >> of sems threads running, also the virtual memory usage raises to >> unbelievable high values (~30GB, while there is only 4GB memory >> available). I did not see any relation between the Calls/Traces and the >> hanging threads. >> >> I am only using sbc (load_plugins=sbc;session_timer;monitoring;stats) >> module, so the problem is probably in the sbc module and not a general >> sems core Problem? > you'll definitely need to hunt down the call flow where the call is > not properly ended in the sbc module. does sems-stats show you the > proper number of calls? If you can't run sems in debug mode, I'd put > some INFO level statements in the sbc app, and postprocess them to > filter out the calls that stay there. If you can replay some of your > traffic against a test instance, it might be even simpler. > > I'd suspect that it's calls that are not really established which are > hanging in sems. > > Have you tried a newer version from git master whether you also get > hanging calls there? You might just be much better off with that. > >> >> >> There is nothing fancy about the config, except in the profile i got: >> >> outbound_interface=$P(q) >> >> So the outbound_interface is a variable not a static string. This seems >> to work fine, but could this have any other side effects? > > no, not really. > > Stefan > _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
