Opened 4 years ago

Closed 20 months ago

#1461 closed defect (no response)

Reject tunnels if Linux's load average is above 1

Reported by: vi Owned by:
Priority: minor Milestone: undecided
Component: router/general Version: 0.9.17
Keywords: Cc:
Parent Tickets:

Description

Looks like load average on a VM running I2P is proportional to the number of participating tunnels. Once it is near 1000, the system becomes unresponsive (including for other services on the same VM), job lag increases, etc.

I think it would be a nice idea to limit maximum participating tunnels based on /proc/loadavg. This also would allow automatic shrinking of I2P activity in case of other load is present on the same system.

Subtickets

Change History (3)

comment:1 Changed 4 years ago by echelon

Moin

bad idea, I do not see any issues with it. I do run several I2P routers in VMs and on standard linux systems, even with a high load >2000 participating tunnels, and they all do behave well, even with a load >10.
And if a machine is hogged, the message delay time gets up and the accepting of new participating tunnel is closed/limited.
Result: loaded server does not accept more tunnels, thats what you wanted, already implemented.

Last edited 4 years ago by echelon (previous) (diff)

comment:2 Changed 4 years ago by zzz

  • Component changed from unspecified to router/general
  • Status changed from new to infoneeded_new
  • Type changed from enhancement to defect

Agreed. The load average is of course linux-only, and is only loosely related to whether I2P is getting enough CPU.

We already have several checks to reject tunnels when we think we are running behind. The primary one is a check for the time from when a build request is received to when it is processed. If tht limit is exceeded there will be a message in the summary bar saying "Dropping tunnel requests: too slow".

Do you see that message?

Also, I looked at the way we look at the job lag, which is another measure of delay, and I think we could improve it.

What's the job lag listed in the summmary bar when it goes bad? Can you guess what the threshold is between a good and bad job lag?

comment:3 Changed 20 months ago by zzz

  • Resolution set to no response
  • Status changed from infoneeded_new to closed
Note: See TracTickets for help on using tickets.