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
