In case of session threadpool there can be "unlimited" number of sessions
attached to one thread. There are several such threads and sessions are assigned
to them upon creation ... so I would say you won't consume system resources
(memory in this case) that quickly as with one thread per each new session.
Currently I'm not sure whether it is possible to show all existing sessions
(might be using monitoring module) including their duration. This would help for
detecting such sessions and running tcpdump in parallel on signaling ports might
help to find the problematic scenario.
Vaclav
On Pá, úno 21, 2014 at 02:56:05 +0100, Max Mühlbronner wrote:
> Hi,
>
> thanks for your reply, indeed this was already suggested by someone on
> the list some time ago.
>
> But, as you said this would be even more problematic because we would
> quickly reach the threadpool Limit and no further calls would be accepted?
>
>
> I really tried everything to find the "broken" call scenarios, but i was
> not able to find any relation of the threads to non-terminated calls.
> Also the gateways/proxies involved are using sst/rtp timeouts/timers so
> it would be really strange if there are so many orphaned calls/dialogs.
>
>
> But maybe this is the right direction, i will take another look into the
> issue. Thanks.
>
>
> Best Regards
>
> Max M.
>
> On 02/21/2014 01:57 PM, Václav Kubart wrote:
> > Hi Max,
> > my guess is that you are not using thread pool for sessions and there is a
> > call
> > scenario that causes sessions not to be terminated correctly.
> >
> > I would suggest to compile sems with USE_THREADPOOL=yes and then you can
> > control
> > number of threads for processing signaling in sems config file (and the
> > number
> > of threads shouldn't grow).
> >
> > Anyway the sessions will stay there probably as well, you would need to
> > find the
> > "broken" call scenario.
> >
> > Vaclav
> >
> > On Pá, úno 21, 2014 at 01:32:10 +0100, Max Mühlbronner wrote:
> >> 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?
> >>
> >>
> >> 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?
> >>
> >>
> >> root 1871 1 18581 0 5044 04:07 ? 00:00:00
> >> /usr/sbin/sems -P /var/run/sems/sems.pid -u root -g root -f
> >> /etc/sems/sems.conf
> >> root 1871 1 4342 0 5044 04:31 ? 00:00:00
> >> /usr/sbin/sems -P /var/run/sems/sems.pid -u root -g root -f
> >> /etc/sems/sems.conf
> >> root 1871 1 19762 0 5044 04:50 ? 00:00:00
> >> /usr/sbin/sems -P /var/run/sems/sems.pid -u root -g root -f
> >> /etc/sems/sems.conf
> >>
> >>
> >> Another thing: ERROR: getnameinfo() failed: ai_family not supported
> >>
> >> At first i thought this was related to ipv6, which is disabled now. But
> >> still the errors are coming in every few seconds. But i am not sure if
> >> this is a hint to my problem?
> >>
> >>
> >> To be fair, this is a virtual machine (KVM) but i already tested and got
> >> the same results when running on a dedicated server.
> >>
> >>
> >> Any ideas?
> >>
> >>
> >> --
> >> Max Mühlbronner
> >>
> >> 42com Telecommunication GmbH
> >> Straße der Pariser Kommune 12-16
> >> 10243 Berlin
> >>
> >> E-Mail: [email protected]
> >> Web: www.42com.com
> >>
> >> Firmenangaben/Company information:
> >> Handelsregister/Commercial register: Amtsgericht Berlin HRB 99071 B
> >> Umsatzsteuer-ID/VAT-ID: DE223812306
> >> Geschäftsführer/CEO: Thomas Reinig, Alexander Reinig
> >>
> >> Diese E-Mail enthält Informationen von 42com Telecommunication GmbH.
> >> Diese sind möglicherweise vertraulich und ausschließlich für den
> >> Adressaten bestimmt. Sollten Sie diese elektronische Nachricht
> >> irrtümlicherweise erhalten haben, so informieren Sie uns bitte
> >> unverzüglich telefonisch oder per E-Mail.
> >>
> >> This message is intended only for the use of the individual or entity to
> >> which it is addressed. If you have received this message by mistake,
> >> please notify us immediately.
> >> _______________________________________________
> >> Sems mailing list
> >> [email protected]
> >> http://lists.iptel.org/mailman/listinfo/sems
>
>
> _______________________________________________
> Sems mailing list
> [email protected]
> http://lists.iptel.org/mailman/listinfo/sems
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
