High Wait Time and CPU Usage with Oracle.ManagedDataAccess in High-Concurrency .NET 8 Environment

[FabioDantasBmg]

Description:
We are experiencing high wait times and CPU usage in our .NET 8 application using Oracle.ManagedDataAccess (ODP.NET Managed Driver) under high concurrency. The issue is most evident in Kubernetes environments with many pods and a high minimum pool size.

Environment:

• .NET 8
• Oracle.ManagedDataAccess (please specify exact version)
• Connection string:
  User Id=###;Password=###;Data Source=###;VALIDATE CONNECTION=True;Persist Security Info=True;Max Pool Size=100;Connection Lifetime=120;Min Pool Size=30;CONNECTION TIMEOUT=60;POOLING=True;
• 20+ pods (Kubernetes), each with its own pool
• ~2,500 requests/minute

Symptoms:

• Endpoints spend most of their time waiting for Oracle operations, not on SQL execution itself (confirmed by Dynatrace traces).
• SQL queries are fast when run directly on the database.
• High CPU usage in some pods, resolved only by restarting the pod.
• No apparent locks or slowdowns in the Oracle database itself.

What we have tried:

• Increased Connection Lifetime to 600s (testing).
• Monitored pool usage and resource consumption.
• Ensured queries are optimized.

[alexkeh]

To diagnose the problem, you'll need to collect at least an ODP.NET trace and probably performance profiling information. That will identify which part of ODP.NET operations are slow. For example, the problem could be in creating connections, or some queries could execute slowly on the ODP.NET side, or it's taking a while to retrieve results.

If most ODP.NET operations are behaving slowly, the pod itself could be starved for resources. You could then review if there's enough memory, CPU, etc. If there's not enough, you could add more hardware.

If there are enough resources for the load, we can review the code to determine if it's efficient for its use profile. The ODP.NET team can also review if there are ways to make ODP.NET Core more efficient internally.

Which ODP.NET Core version are you using?

[FabioDantasBmg]

Thans for your quick response Alex.

We are using "Oracle.ManagedDataAccess.Core" Version="23.8.0".

I can only display the hostpot at the time of high consumption, and it is in this process:

Top hotspot

Method
ReaderStream+d_20.MoveNext

Overall contribution
97.8%

Our pods does not time out or exceed limit, and we will monitor resource usage during the next incident.

If you need any specific trace configuration or additional details, please let us know.

[alexkeh]

One way to improve your connection time is to remove "Validate Connection=true" from the connection string. That will eliminate a round trip for every connection open request. To ensure a valid connection from the pool, you can use Oracle Fast Connection Failover instead. Oracle Application Continuity is also an option; however, FCF is a lighter-weight solution as it primarily handles planned maintenance scenarios, which is the most common outage type.

Did you run a similar workload concurrency with an earlier ODP.NET Core version that didn't have high CPU/wait time? If so, what version was it?

The ReaderStream MoveNext would suggest results being retrieved from the DB. Does this happen with specific data retrieval, such as LOBs or other non-scalar types?