mirror of https://github.com/sipwise/sems.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
94 lines
5.0 KiB
94 lines
5.0 KiB
* [1]Main Page
|
|
* [2]Related Pages
|
|
* [3]Namespaces
|
|
* [4]Data Structures
|
|
* [5]Files
|
|
* [6]Directories
|
|
* [7]Examples
|
|
|
|
Tuning SEMS for high load
|
|
|
|
For high load, there are several compile and run time options to make
|
|
SEMS run smoothly.
|
|
|
|
When running SEMS, make sure that you have the ulimit for open files
|
|
(process.max-file-descriptor) set to an value which is high enough. You
|
|
may need to adapt raise the system wide hard limit (on Linux see
|
|
/etc/security/limits.conf), or run SEMS as super user. Note that an
|
|
unlimited open files limit is not possible, but it is sufficient to set
|
|
it to some very high value (e.g. ulimit -n 100000).
|
|
|
|
There is a compile-time variable that sets a limit on how many RTP
|
|
sessions are supported concurrently, this is MAX_RTP_SESSIONS. You may
|
|
either add this at compile time to your value, or edit Makefile.defs
|
|
and adapt the value there.
|
|
|
|
SEMS normally uses one thread per session (processing of the
|
|
signaling). This thread sleeps on a mutex (the session's event queue)
|
|
most of the time (RTP/audio processing is handled by the
|
|
[8]AmMediaProcessor threads, which is only a small, configurable,
|
|
number), thus the scheduler should usually not have any performance
|
|
issue with this. The advantage of using a thread per call/session is
|
|
that if the thread blocks due to some blocking operation (DB, file
|
|
etc), processing of other calls is not affected. The downside of using
|
|
a thread per session is that you will spend memory for the stack for
|
|
every thread, which can fill up your system memory quickly, if you have
|
|
many sessions. The default for the stack size is 1M, which for most
|
|
cases is quite a lot, so if memory consumption is an issue, you could
|
|
adapt this in [9]AmThread, at the call to pthread_attr_setstacksize.
|
|
Note that, at least in Linux, the memory is allocated, but if a page is
|
|
not used, the page is not really consumed, which means that most of
|
|
that empty memory space for the stack is not really consumed anyway. If
|
|
you allocate more than system memory for stack, though, thread creation
|
|
may still fail with ENOMEM.
|
|
|
|
You can compile SEMS with thread pool support (see Makefile.defs). This
|
|
improves performance a lot for high CPS applications, e.g. signaling
|
|
only B2BUA apps. You should NOT use threadpool if your applications use
|
|
operations which could be blocking for a longer time (e.g. sleep,
|
|
remote server access which could possibly be non-responsive), because
|
|
one blocked session (call) is blocking all the other sessions (calls)
|
|
that are processed by the same thread. So, for example, if the
|
|
application logic of one call queries a server synchronously which
|
|
takes a few seconds to respond, all the other calls are blocked from
|
|
processing SIP messages and application logic during that time.
|
|
|
|
The reasons a thread pool gives a large performance boost over
|
|
one-thread-per-call for high CPS applications presumably are that
|
|
thread creation takes some time, and the thread scheduling is less
|
|
efficient if there are very many active threads (as opposed to many
|
|
sleeping threads like in usual media server applications, where the
|
|
application/signaling threads sleep most of the time, while only the
|
|
media/RTP processing threads are active).
|
|
|
|
On top of that, you save lots of memory (mostly the stack memory),
|
|
also, because of STL memory allocator.
|
|
|
|
If you notice retransmissions or even failing calls, but the CPU load
|
|
is not at 100%, there may be several reasons for it:
|
|
* SIP messages are dropped when sending, because the NIC/network is
|
|
not fast enough in accepting all the packets written to its queue
|
|
and putting them on the network (you can check this with your OS,
|
|
for newer Linux in /proc, check dropped packets on send for the SIP
|
|
port)
|
|
* there is contention on some mutexes -> adapt EVENT_DISPATCHER_POWER
|
|
in [10]AmEventDispatcher.h -> add striping for some other Mutexes
|
|
__________________________________________________________________
|
|
|
|
|
|
Generated on Thu Feb 3 02:29:25 2011 for SEMS by [11]doxygen 1.6.1
|
|
|
|
References
|
|
|
|
1. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/index.html
|
|
2. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/pages.html
|
|
3. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/namespaces.html
|
|
4. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/annotated.html
|
|
5. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/files.html
|
|
6. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/dirs.html
|
|
7. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/examples.html
|
|
8. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/classAmMediaProcessor.html
|
|
9. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/classAmThread.html
|
|
10. file://localhost/home/stefan/devel/sems/sems/doc/doxygen_doc/html/AmEventDispatcher_8h_source.html
|
|
11. http://www.doxygen.org/index.html
|