Bug #1436

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

Added by Anonymous almost 3 years ago. Updated over 1 year ago.

Status:Fixed Start:
Priority:Urgent Due date:
Assigned to: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 1 year ago

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

Revision 2454
Added by stbuehler over 1 year ago

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

History

Updated by Anonymous almost 3 years ago

Yes I'm experiencing the same thing.

-- ServerTweak.com

Updated by Anonymous over 2 years ago

Same here, any suggestions?

-- Robert Klikics

Updated by stbuehler almost 2 years ago

  • Status changed from New to Assigned

Updated by stbuehler almost 2 years ago

  • Target version changed from 1.4.20 to 1.4.21

Updated by manik almost 2 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.

Updated by stbuehler over 1 year ago

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

Applied in changeset r2387.

Also available in: Atom