Skip to main content

We have an issue for session from the odata pod that doesn't seem to not release the PGA memory consumption for the shared db sessions from the odata pod. They are never recycled in the IFSAPP-ODATA pods connection pool and just increase and increase. When they reach aprox 400 mb they start getting issues for other users session accessing the the connect. during logon on a statement BEGIN alter session set current schema to ‘IFSAPP’ END that hangs for 40 to 70 seconds with wait event SQL*Net message from client. This impact the database server performance when you have multiple sessions of it. with high cpu load

To recreate it fast it’s possible to recreate it by do a sort and search inside the Entity Configuration screen. You will quite fast see that the database session will use above 400Mb quite fast and stay there for ever. If you then want to get more of them. Just open the same page multiple times in different tabs and add sort and push search… Then you even got more sessions whit high memory consumption.

Anyone seen this issue and have an solution to it?

Is it possible to do any configuration for the ifsapp-odata pod connection pool to recycles the oracle session on a regular basis to free up the dababase session pga memory consumption?

 

Or is it an bug in the frameworkl not releasin cursors ore something for the shared sessions. The same behavior is found in 22R1 su4 su 10 su 11 22R2 su 3

 

Hi kjroSidekick,

Has this issue been resolved?


Recycling was introduced with 22r2Su8 but sadly it didn’t work as expected. I have an case against IFS to get it sorted but the latest information is that they aim for for a correction in 24R1. It’s a bit long away and I have asked the question if the would like to sort it in existing version to. So let’s see IFS ifs wan’t to fix recycling in older versions to.

 

We have managed to figure out a solution for the freez situation.

 

Addovation AS on Linked In

Linkedin profil 


Reply