Can I track the Active sessions

Hello,

I'm trying ti investigate the spike in our Active Session. Rule or schedule job executed cause the Active Session to jump from ~1200 to 3500(Limit)
So far I'm not able to determent from which tenant this is coming or from which record. We have 2 tenants.

I'm hoping someone to had similar experience to exchange knowledge

Many Thanks,
Miro

  • 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