Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reducing high memory consumption #348

Open
eugene-krivobokov opened this issue May 27, 2024 · 3 comments
Open

Reducing high memory consumption #348

eugene-krivobokov opened this issue May 27, 2024 · 3 comments

Comments

@eugene-krivobokov
Copy link
Contributor

Hi!

There was a report about a potential memory leak: #247
It turned out that this is expected and the plugin stores a quite detailed information about build operations to make needed calculation.

The thing is that memory consumption increases so big that it makes using of the plugin problematic on big projects.
In my environment this is the top-1 memory consumer.

Therefore, I'd like to revive this topic to clarify potential improvements, if possible.

  • Would it be possible to store this information only for checks that consume it?
  • Are there any ideas to reduce the amount of data or calculate and discard on the fly?

With plugin:
Screenshot from 2024-05-27 19-40-58

with_plugin

Without plugin:
without_plugin

@runningcode
Copy link
Owner

Hi @eugene-krivobokov thanks for bringing this up. I'm very open to ideas on how to improve this.

I'm wondering, is the memory still retained after a single build completes? At least in the way it is built, it is intentional that these objects are retained during a single build, but not from one build to the next.

@eugene-krivobokov
Copy link
Contributor Author

Hi! The memory is released after the build completes. The issue is with high memory consumption while the build is running. It's a limiting factor on laptops, where we can't increase memory easily.

In general, I know two approaches.

  1. Collect this information only if features that actually use it are enabled. In that case, we can use at least some functionality instead of disabling the whole plugin.
  2. Aggregate metrics on the fly with each new piece of tracked operations. Not sure, if this is feasible.

@osipxd
Copy link

osipxd commented Nov 21, 2024

Found a workaround to disable BuildOperations collection

build.gradle.kts

// Disable task monitoring by default providing an option to opt-in.
// See 'doctor.enableTaskMonitoring' in gradle.properties for details.
val enableTasksMonitoring = properties.getOrDefault("doctor.enableTaskMonitoring", "false").toString().toBoolean()

if (!enableTasksMonitoring) {
    logger.info("Gradle Doctor task monitoring is disabled.")
    gradle.sharedServices.unregister("listener-service")
}

fun BuildServiceRegistry.unregister(name: String) {
    val registration = registrations.getByName(name)
    registrations.remove(registration)
    (registration.service as RegisteredBuildServiceProvider<*, *>).maybeStop()
}

gradle.properties

# Gradle Doctor might increase memory consumption when task monitoring is enabled, so it is disabled by default.
# Some features can't work without task monitoring:
#  doctor-negative-savings, doctor-slow-build-cache-connection, doctor-slow-maven-connection
# Issue: https://github.com/runningcode/gradle-doctor/issues/348
doctor.enableTaskMonitoring=false

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants