Klaus Darilion schrieb:
That's the point. The server does nearly nothing:
I have 10 TCP childs and only about 2 INVITEs/sec.
Then there is probably
something going wrong.
I would:
- stop the proxy and all clients
- start tcpdump or wireshark (without capture filter)
- start the clients (if you have clients)
- make a single call, hang up
- repeat the single call, hang up.
Then analyze the capture file: Are there "strange" SYN packets trying to
establish a connection which does not work? Are there other TCP errors
(RST, FIN ...)
I suspect that workers are trying to establish new tcp connection which
do trigger a timeout - and as TCP handling in Kamailio is blocking the
TCP workers are busy when new requests are received.
I've check the traces and can not see any suspicious SYNs etc. All looks
fine.
But I recognized that the "no free tcp receiver" comes along with a
"CRITICAL:core:handle_io: empty fd map" messages. Nevertheless, I have
no clue at all...
Just for clarification: if I have 5 TCP children, then only 4 childs are
worker processes. If a sip peering partner with 4 different SIP server
has a network split, all my worker childs are blocked and wait for TCP
timeouts. In the meantime, no calls to anywhere else is possible. Right?
It depends. e.g.
- Kamailio receives request which should be sent to
sip:user@1.1.1.1;transport=tcp: Kamailio will open TCP connection, will
write to the socket in blocking mode. That means that one single worker
process (either a UDP worker if the request was received via UDP or a
TCP worker if the request was received via TCP) is blocked until the TCP
ACK is received from the destination and the writing to the socket
returns. Then this TCP connection is moved to the connection pool and
then this worker process is free for some other tasks.
If the server on 1.1.1.1 does not answer to TCP packets, this single
processed is blocked. For example, if you send 4 INVITE requests to the
proxy afdressing 4 servers which do not exist - then 4 workers will
block until the TCP handshake timeout will trigger.
But if everything is fine you can have handle hundreds of TCP connection
with a few worker processes - the requests are processes one after the
other and the currently not needed TCP connections will be put to the
TCP connection pool meanwhile.
regards
klaus