dccm failure under load

On Sat, Jan 04, 2003 at 11:24:21PM -0700, Vernon Schryver wrote:
> 
> When sendmail starts talking to an SMTP clients, it creates TCP
> connections to all milter filters.  Each milter filter creates
> a thread and calls the initial hook of the filter.  The initial
> milter hook for dccm involves finding a free "context" or creating one.
> Each dccm context contains various data including growing checksums
> and eventually a file descriptor for a UDP socket to talk to a DCC server.
> For speed, the UDP socket is not closed when the dccm thread is finished
> and the dccm "context" is released.

Thanks for the explanation.  So, they will be sockets associated with
idle contexts.  That's reasonable.

> 153 dccm threads will involve somewhat more than 459 file descritors.
> Each thread will have a TCP UNIX-domain connection to sendmail, a UDP
> socket for talking to the DCC server, and a log file.  If per-user
> log files are used, there will be a transient fourth file descriptor
> per thread.  There are few dozen file descriptors for the global white-list
> and per-user white-lists.  The client DCC map will involve another
> file descriptor.  There are likely to be open file descriptors hidden
> libc routines such the DNS resolver code.  Solaris seems to involve
> about two dozen file descritors for shared libraries.  So overall,
> 598 file descriptors sounds about right for somewhat fewer than 200
> dccm threads without per-user whitelists or per-user log files.

I wonder then, if `dccm' is setting the file descriptor limit too low?
The code looks like this:

        i = max_work*2+EXTRA_FILES;
        old_rlim_cur = nofile.rlim_cur;
        if (old_rlim_cur < i) {
                nofile.rlim_cur = i;
                if (0 > setrlimit(RLIMIT_NOFILE, &nofile)) {


-- 
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-