We’ve been experiencing some huge slowdowns of boundary with a call to the sessions API endpoints taking up to 90s
After looking at boundary database content, we did noticed in session_list view around 24k+ sessions in active state and 25k+ sessions in pending state.
Our only solution was to manually purge the sessions to return to normal performances: DELETE FROM session WHERE create_time < NOW() - INTERVAL '1 days';
I don’t have any debugging help to offer, but if this is easily reproducible, can you test again with 0.7.6? There have been some changes around session handling in that version. I don’t know if any of them would fix your issue, but it would be a useful data point either way.
Hi, thanks for reporting this. One thing to note, the cleanup job that you reference does not delete the sessions from the database, but rather transitions the sessions the to terminated state. It looks for:
// * sessions that have exhausted their connection limit and all their connections are closed.
// * sessions that are expired and all their connections are closed.
// * sessions that are canceling and all their connections are closed
That said I would expect sessions that are older then 8 hours to be expired, unless the targets are configured with a longer session_max_seconds. And that the expired sessions would be transitioned to the terminated state. Can you provide some additional details:
Can you confirm what the session_max_seconds is for the corresponding targets?
Are there any error logs from either the controllers or workers?
What are the session API calls that are being made? Are they from the Desktop Client or from the CLI?
@omkensey I will try to see if we can upgrade to 0.7.6. But I seems to remember that every time we upgrade, we have to ask users to generate new passwords