Gawith schrieb:
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