We've been observing sustained high CPU utilization (consistently 75-90%) on our PingFederate 10.3 runtime nodes for the past several weeks, which is a significant deviation from our established baseline. The puzzling aspect is that our standard diagnostic logs—the `PingFederate` server log, `access` log, and `audit` log—show no corresponding errors, warnings, or a noticeable spike in request volume that would obviously correlate. Performance appears functional from an end-user perspective, but the resource consumption is concerning for both longevity and our ability to handle genuine load spikes.
Our environment consists of a four-node cluster behind a load balancer, and the high CPU is uniform across all nodes. We've already conducted the following initial investigative steps:
* Verified the JVM heap and non-heap memory settings are within recommended parameters and garbage collection logs show normal patterns.
* Confirmed there are no runaway `java` processes; it's specifically the primary PingFederate service process.
* Reviewed operating system-level metrics, which show no disk I/O or network saturation.
* Temporarily disabled non-essential adapters and connections to see if a specific integration was the source, with no change in CPU profile.
The lack of log evidence has led us to suspect something at the thread level or a configuration-driven inefficiency. I am particularly interested in community experiences with the following scenarios:
* **Diagnostic Tools:** Beyond the standard logs, which specific JVM tools or PingFederate-specific monitoring endpoints have you found most effective for pinpointing thread contention or specific high-CPU operations? We are familiar with taking thread dumps, but interpreting them in the context of Ping's internal worker pools is challenging.
* **Configuration Pitfalls:** Are there known, less-obvious configuration settings related to session polling, metadata refresh intervals, or background validation checks that can become resource-intensive as the configuration grows? Our instance manages a substantial number of partner connections and OAuth clients.
* **Version-Specific Behavior:** Has anyone observed similar silent high CPU in the 10.3.x branch that might be tied to a particular patch or feature enablement? We are considering an upgrade path but need to stabilize the current state first.
We are currently planning to enable more granular JMX monitoring and profile the internal worker threads, but any direct experience or a checklist of known resource-intensive background processes would be invaluable. The absence of errors makes this feel like a performance antipattern rather than a failure, which is why traditional log analysis is coming up short.
Support is a product, not a department.
Interesting that it's uniform across all four nodes. That points away from a local config issue and toward something systemic in your deployment or traffic.
You mentioned temporarily disabling non-essential adapters. Did you by chance add or update any adapters, OIDC policies, or contract mappings a few weeks back? Sometimes a new attribute mapping or script can be "correct" but incredibly inefficient, getting evaluated on every request without throwing an error. It just burns CPU quietly.
Also, have you checked what's actually generating load? Not just volume, but type. A surge in back-channel SAML artifact resolution or a misbehaving partner constantly hitting your metadata endpoint could do this without making a huge dent in the access logs you normally monitor. Might be time for a packet capture on a node to see what's really churning.
—DW
Totally agree that the uniform CPU across all nodes makes it a shared traffic or config issue, not a local one.
One angle I've seen bite us before is a caching change. If something like the SAML metadata cache or the IdP adapter contract cache got tweaked inadvertently, it could force a full re-evaluation on every single request instead of a cache hit. That'll hammer CPU quietly across the board.
You mentioned disabling non-essential adapters and connections. Did that include turning off any new partner connections one by one? Sometimes a single integration with a buggy SP-initiated flow can be the culprit, and it's hard to spot in the general request volume.