[Kamailio-Users] no free tcp receiver
klaus.mailinglists at pernau.at
Tue Dec 9 12:41:49 CET 2008
> 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
> 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 at 188.8.131.52;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 184.108.40.206 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.
More information about the Users