Configuring a large number of sessions affects performance even if the sessions are never used – this is a problem because applications don't think of the number of configured sessions as a tuning parameter and simply configure enough to be "safe".

The problem is that the hazard reference check, during eviction, reviews all of the configured session's hazard arrays, many or most of which are unused.

The solution is to add a volatile "max-sessions" value on the connection handle that is the maximum number of concurrent sessions in the system. (I think volatile is sufficient?) The hazard reference check would save a copy of max-sessions as it starts its search, and compare that value against the original when it completes the search – if the number of max-sessions has grown, the search has to be repeated. (It's wildly unlikely a session could be created and manage to acquire a hazard reference during the time the eviction thread is reviewing the hazard references for a page, but it's theoretically possible.)

We should also decrement the max-sessions value, but decrementing the value would not require the hazard reference check to be repeated.

We should increment/decrement the number of max-sessions by some chunk (maybe 10 or 20?) at a time, so we don't end up bouncing around if sessions are being created/deleted at a regular rate.