Miro,

"Active sessions" may mean different things. Where is this information coming from? How did you get to these numbers?

Best regards,

Brindusa

Hi Brindusa,

Opening the SMAX DB with pgAdmin I see the following:

This is normal load and SMAX is working fine.

During some peek events we consume all the Active Session available which start causing problem:
- pods are restarting
- OO is not able to communicate with SMAX
- end user are not able to access SMAX, etc

This is on MAX connections:


We stay in this situation for live 15-20 min and then everything is back to normal.

We don't have vaccum enables during working hours.

Regards,
Miro

Hello

Thank you for clarifying the question is about database sessions.

There is no procedure to distinguish, as the sessions are not dedicated per tenant.

If you have the capability, you could look at query statistics and check if there is anything obvious.

Alternatively, assuming the load is generated from outside, you can analyze the access logs, extract the REST API URLs and check for patterns.

Best regards,

Brindusa

Thank you Brindusa for coming back to me topic.

Yes, I agree with you what I'm asking is odd and strange.

This is what we are trying to pin-point with SQL queries for "Active" calls during spike performance:

SELECT now() - query_start as "runtime", usename, datname, state, query
  FROM  pg_stat_activity
  WHERE state='active'
 ORDER BY runtime DESC;

Problem with above is that in the query I don't the Entity ID from which the query is trigger.

Yes, currently check  access.log foe glue.

My assumption is schedule rule trigger update on multiple records, and since they are highly customize.

Once again, thank you Brindusa