This note is about running search(1) as a daemon under Solaris
where it will be expected to service a large number of requests
per unit time.
The first side of a TCP connection to close it goes into the
TIME-WAIT state. From RFC 1122:
The graceful close algorithm of TCP requires
that the connection state remain defined on (at
least) one end of the connection, for a timeout
period of 2xMSL, i.e., 4 minutes. During this
period, the (remote socket, local socket) pair
that defines the connection is busy and cannot
The request/response class of servers, such as web servers and
search(1), tend to close the connection first. From the above,
this means that such a server's socket goes into the TIME-WAIT
Under sustained heavy load, the server will run out of
resources for sockets because they will be needed for new
requests faster than they are coming out of TIME-WAIT.
The Solaris TCP stack implements the quoted section of RFC 1122
above to the letter. The 4-minute wait can be considered too
long by some. To change that to, say, 1 minute, you can do:
ndd -set /dev/tcp tcp_time_wait_interval 60000
Solaris also starts ephemeral port allocation unusually high at
32768. Ephemeral ports can start at 1024. To change this, you
ndd -set /dev/tcp tcp_smallest_anon_port 1024
The above two changes will buy the server more time before it
runs out of socket resources, but under sustained heavy load,
it will still run out eventually.
The best thing to do is to ensure that any search(1) clients
you write call shutdown(2) after they have finished sending
their request. This will cause them to go into TIME-WAIT
instead of the server.
Note: this isn't a problem under Linux because, as far as I can
tell, Linux violates RFC 1122 by allowing sockets in TIME-WAIT
to be used for new connections. Despite the violation, it
works out for the best in the case of servers.