Metaspace OOM after upgrade to 9.9

SonarQube Server / Community Build
, ,
1

Hi team,

  • What version are you upgrading from? 9.6.1.59531

  • System information (Operating system, Java version, Database provider/version)
    Operating System: amd64, Linux 5.15.0-1028-aws
    Java Version: 17.0.6
    Database provider / version: PostgreSQL, 12.12

  • What’s the issue you’re facing?
    We are seeing scans from Github Actions fail after upgrade due to OOM. The same code was passing before upgrade.

----- Last  20 lines from daemon log file - daemon-3239.out.log -----
06:17:00.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on daemon addresses registry.
06:17:00.056 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
06:17:00.056 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
06:17:00.058 [DEBUG] [org.gradle.launcher.daemon.server.DaemonStateCoordinator] daemon is running. Sleeping until state changes.
06:17:00.058 [WARN] [org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler] Unable to execute command Build from socket connection from /127.0.0.1:36551 to /127.0.0.1:40252. Dispatching the failure to the daemon client
java.lang.OutOfMemoryError: Metaspace
06:17:00.538 [DEBUG] [org.gradle.launcher.daemon.server.DefaultIncomingConnectionHandler] Finishing executing command: Build
06:17:00.538 [DEBUG] [org.gradle.launcher.daemon.server.health.DaemonMemoryStatus] non-heap: GC rate: 0.00/s non-heap usage: 95%
06:17:00.539 [INFO] [org.gradle.launcher.daemon.server.health.LowNonHeapDaemonExpirationStrategy] Expiring Daemon due to JVM Metaspace space being exhausted
06:17:00.539 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
06:17:00.539 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
06:17:00.539 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 17: stopping connection
06:17:00.539 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
06:17:00.540 [DEBUG] [org.gradle.internal.remote.internal.inet.SocketConnection] Discarding EOFException: java.io.EOFException
06:17:00.540 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 128: received null
06:17:00.540 [DEBUG] [org.gradle.launcher.daemon.server.DefaultDaemonConnection] thread 128: Received end-of-input from client.
06:17:00.540 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
06:17:00.540 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
06:17:00.540 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
06:17:00.541 [DEBUG] [org.gradle.launcher.daemon.server.DaemonRegistryUpdater] Storing daemon stop event: after running out of JVM memory
----- End of the daemon log -----


FAILURE: Build failed with an exception.

* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

Updating metaspace size fixed the issue but is this expected? Was the failure caused by the upgrade? Were there any new checks or existing checks that now require more memory / low defaults?

Thanks.

2

Hi,

It’s not clear from your logs at what point in the process analysis ran out of memory. But with each release, we add new rules and improve others. So I wouldn’t say that this is necessarily expected, but it’s not surprising that more memory was required.

That said, this might deserve a note in the LTS to LTS upgrade notes. I’ll ping internally on that.

Thanks for the note!

 
Ann

1 Like