Re: Dormant FD usage.

> Well, now that the bugs are ironed out, I have another situation. Here's
> some stats for squid:
>
> File descriptor usage for squid:
> Max number of file desc available: 1024
> Largest file desc currently in use: 739
> Available number of file descriptors: 285
> Reserved number of file descriptors: 100
>
> 739! I thought - that's can't be right... I looked at the FD Usage option
> in the cachemgr only to find that there are literally *heaps* of what you
> could call 'open' processes of squid trying to get gifs, htmls etc. Yet
> when I look in the access.log file I find *NO* log of this.

Well spotted. We thought 1.1 was using more fd's than the old 1.0 code.

The client has closed the socket, and select() will return a status
saying that there is something to read on the socket, i.e. the EOF
indication. In icp.c:icpDetectClientClose() this is were the read is
handled, and n == 0 so this code is executed,
    } else {
        debug(12, 5, "icpDetectClientClose: FD %d closed?\n", fd);
        comm_set_stall(fd, 10); /* check again in 10 seconds */
    }

This does nothing because the read handler has not been re set, i.e. this
isn't done.
    commSetSelect(fd,
        COMM_SELECT_READ,
        icpDetectClientClose,
        (void *) icpState,
        0);

Even so, the state is not going to change. Eventually the socket will
time out and asciiConnLifetimeHandle() will clean up (after quite a long
delay). I think icpDetectClientClose() needs to do the same sort of
processing that asciiConnLifetimeHandle() is eventually doing.

 - Mark.
Received on Mon Mar 31 1997 - 20:45:51 MST