https://kotlinlang.org logo
j

Joe

11/01/2019, 12:14 AM
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?
d

Dariusz Kuc

11/03/2019, 3:31 PM
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?
j

Joe

11/03/2019, 9:44 PM
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
d

Dariusz Kuc

11/04/2019, 2:49 AM
unfortunately those build logs don't tell much 😞
j

Joe

11/04/2019, 3:18 AM
yeah, just that 137 means the container used > 4G memory and processes got killed
d

Dariusz Kuc

11/04/2019, 3:29 PM
when running it locally i do see higher memory usage by
ClassGraph
vs
Reflections
libs
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
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
I'm thinking we should enforce specifying at least single package
j

Joe

11/04/2019, 4:37 PM
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?
d

Dariusz Kuc

11/04/2019, 4:56 PM
instead of
java.lang
you should be pointing to
com.trib3.graphql
or something like that
haven't checked but i think you were also running test ng in parallel which ended up with consuming more memory as well
j

Joe

11/04/2019, 7:20 PM
yeah we are running tests in parallel. looks like pointing to
com.trib3.graphql.subpackage
does pass without tweaking the memory settings fwiw
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)...
8 Views