[Date Prev][Date Next]
Re: (ITS#4160) idletimeout configuration directive being processed late
Quanah Gibson-Mount wrote:
> --On Tuesday, November 08, 2005 1:25 AM -0800 Howard Chu
> <firstname.lastname@example.org> wrote:
>> I think this is more to do with server load than anything else. Note
>> in the absence of other activity the server only checks once every
>> (idletime/4) seconds for idle connections. So given a 30 second
>> idletimeout a lag of up to 7.5 seconds would be normal. The 41 second
>> interval there (11 second lag) does seem a bit abnormal, but the 37 and
>> 35 second intervals are fine.
> I dunno... Even on an extremely idle system at 4 in the morning I see:
> Nov 8 04:21:44 ldap9.Stanford.EDU slapd: [ID 588225
> local4.debug] conn=2297 op=0 RESULT tag=97 err=0 text=
> Nov 8 04:22:22 ldap9.Stanford.EDU slapd: [ID 485650
> local4.debug] conn=2297 fd=80 closed (idletimeout)
> Although I suppose that is close to:
> 44+30 = :14 +7.5 (probably rounded to 8) = :22.
> Is it perhaps doing (idletime + (idletime/4)) seconds?
Not intentionally. As I said, it will only check once every idletime/4
seconds. The total lag depends on when the check occurs relative to when
the last activity on a connection occurred. E.g., in the worst case the
first check occurs ~7.4 seconds after the last activity on a connection
(time t). So four polls will occur with no action being taken: t+7.4,
t+14.9, t+22.4, and t+29.9. The first poll that exceeds the 30 second
limit will be at t+37.4, giving you the worst case ~7.5 second lag.
You can redefine the SLAPD_IDLE_CHECK_LIMIT in daemon.c if you want it
to check more frequently, but I think that would be a waste of CPU.
Showing a lag of 11 seconds implies that the listener thread got too
busy handling connections; after waking up from select() it had too much
to do to be able to get back to the top of the loop. That definitely
seems unusual, but not impossible and not an indication of an actual
software error. I would expect the Lightweight Dispatcher code to
eliminate these occurrences, you could enable that in the RE23 build and
see if you still notice these large delays.
At any rate, I don't think there's a bug here and this ITS should be closed.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/