Bug #1436

when server.max-connections is hit cpu load dramatically increases

Added by Anonymous almost 7 years ago. Updated over 5 years ago.

Status:FixedStart date:
Priority:UrgentDue date:
Assignee:stbuehler% Done:

100%

Category:core
Target version:1.4.21
Missing in 1.5.x:

Description

it seems that as soon as server.max-connections is hit lighttpd becomes very busy turning new connections away, easily jumping to 100% cpu load.

this is on linux, observed with several machines

-- w1zzard


Related issues

Duplicated by Bug #577: lighttpd terminally ceases serving connections when serve... Fixed

Associated revisions

Revision 2387
Added by stbuehler over 5 years ago

Fix max-connection limit handling/100% cpu usage (fixes #1436)

Revision 2454
Added by stbuehler over 5 years ago

merge: Fix max-connection limit handling/100% cpu usage (#1436)

History

#1 Updated by Anonymous almost 7 years ago

Yes I'm experiencing the same thing.

-- ServerTweak.com

#2 Updated by Anonymous over 6 years ago

Same here, any suggestions?

-- Robert Klikics

#3 Updated by stbuehler almost 6 years ago

  • Status changed from New to Assigned

#4 Updated by stbuehler almost 6 years ago

  • Target version changed from 1.4.20 to 1.4.21

#5 Updated by manik almost 6 years ago

Anonymous wrote:

it seems that as soon as server.max-connections is hit lighttpd becomes very busy turning new connections away, easily jumping to 100% cpu load.

this is on linux, observed with several machines

-- w1zzard

this seems to be an artifact of the following code in network.c

/* accept()s at most 100 connections directly
 *
 * we jump out after 100 to give the waiting connections a chance */
for (loops = 0; loops < 100 && NULL != (con = connection_accept(srv, srv_socket)); loops++) {
handler_t r;
connection_state_machine(srv, con);

in connection_accept, a check is made if the number of server connections have been exceeded.

perhaps a fix here would be to avoid going into that loop at all when

srv->conns->used >= srv->max_conns.

#6 Updated by stbuehler over 5 years ago

  • Status changed from Assigned to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2387.

Also available in: Atom