Interesting memory usage behavior we've been seein...

# graphql

[Joe]

Interesting memory usage behavior we've been seeing in graphql-kotlin 1.3.0 vs 1.2.1: When running our unit tests on CircleCI, we're hitting the 4G max memory usage for a container limit. We can get around it by setting JAVA_TOOL_OPTIONS=-XX:MaxRAM=1g, but somewhat concerned that this is newly needed? Has anyone else seen anything similar?

[Dariusz Kuc]

Did not notice it myself - there weren't many changes between the versions, mostly just update from reflections to ClassGraph lib. By any chance could you share some sample project that exhibits this behavior?

[Joe]

https://github.com/trib3/leakycauldron/pull/189 is the dependabot PR, I think you should be able to see the prior failed builds for that branch in circleci as well

[Joe]

direct link to circle build history: https://circleci.com/gh/trib3/leakycauldron/tree/dependabot-maven-com.expediagroup-graphql-kotlin-schema-generator-1.3.0

[Dariusz Kuc]

unfortunately those build logs don't tell much 😞

[Joe]

yeah, just that 137 means the container used > 4G memory and processes got killed

[Dariusz Kuc]

when running it locally i do see higher memory usage by ClassGraph vs Reflections libs

[Dariusz Kuc]

I think part of the reason why you ended up blowing up with OOM is that your tests do not specify list of supported packages

[Dariusz Kuc]

e.g. https://github.com/trib3/leakycauldron/blob/master/graphql/src/test/kotlin/com/trib3/graphql/websocket/GraphQLWebSocketTest.kt#L97

[Dariusz Kuc]

so ClassGraph ends up loading more than intended -> when doing some local testing my memory usage went from slightly over 2GB for the graphl tests to ~800MB after limiting the packages to scan

[Dariusz Kuc]

I'm thinking we should enforce specifying at least single package

[Joe]

hmm, that would make sense to me, but replacing all our tests SchemaGeneratorConfig(listOf()) with SchemaGeneratorConfig(listOf("java.lang")) is still showing the error without a more restricted java memory usage setting; is that not a good way to narrow the scope or do we just need to tweak the mem usage settings better for the restricted CI environment?

[Dariusz Kuc]

instead of java.lang you should be pointing to com.trib3.graphql or something like that

[Dariusz Kuc]

haven't checked but i think you were also running test ng in parallel which ended up with consuming more memory as well

[Joe]

yeah we are running tests in parallel. looks like pointing to com.trib3.graphql.subpackage does pass without tweaking the memory settings fwiw

[Joe]

well, it did once, but not a second time, might just be close to the threshold (also may have been close before the reflections->classgraph change anyway)...