[Date Prev][Date Next]
Re: Too many open files
There are several ways how a lot of or even just one misbehaving
client can render the whole server unusable - intentionally or not.
I think there's quite a number of issues related to this.
Rather than introducing more or less arbitrary delays, I'd suggest
a configurable maximum number of connections per client (= IP address)
to address this issue (yes, more or less intentionally breaking
Also, I'd suggest implementing a complementary setting 'lookthroughlimit'.
It limits the maximum number of entries a single search may examine,
thus limiting the maximum impact one connection may impose on the server.
iplanet already offers that (now, shouldn't *that* be motivation enough :) ?)
Mark Adamson wrote:
> The slapd server here at CMU has been getting into a nasty spin because of
> too many open file descriptors as well. It started last week (while I was
> on vacation, of course :) when someone tried a new client that was making
> a lot of connections to the server.
> I was thinking of putting a check into the slapd_daemon_task() function
> that would notice when a lot of EMFILE errors occur from accept(). If a
> lot of these errors start to pile up, pause between calls to accept() to
> decrease the CPU time spent on accept() failing, thus giving the active
> threads more time to service their connections and close their file
> descriptors. I'm thinking of using a select() call with NULL fd_set's and
> a non-null timeval, instead of a sleep() call, to increase the granularity
> of the delay and decrease mucking with SIGALARM.
> This will be a very experimental work (Kurt is probably pulling his hair
> out reading this) but since there happens to be a thread on this same
> topic as I'm looking into it, I thought I'd mention it too.
> -Mark Adamson
> Carnegie Mellon
tel;fax:++49 +5241 80-67867
tel;work:++49 +5241 80-7867