CODEWITHSUNDEEP
performancescalaplayframeworksbt
bwbecker
bwbecker

Reputation: 1285

sbt high cpu usage with ~run

It seems to me that SBT is taking an excessive amount of CPU time just watching for file changes. I'm aware of this post, but the author there was confounding the IDE cpu time with SBT cpu time; I don't have an IDE running.

I'm developing a Play project in Scala with about 370 scala files divided up into 5 modules.

Running sbt with ~run consumes about 70-90% CPU on my MacBook Pro (mid 2012). I don't have an IDE running, I'm not editing any files, no browser accessing the server... Just idling with ~run (and watching the file system) takes 70-90% of a CPU according to Activity Monitor.

After watching it idle for a while I fired up VisualVM; it shows itself and one other JVM process:

VisualVM overview

Details on the xsbt process (per VisualVM):

PID: 56661
Host: localhost
Main class: xsbt.boot.Boot
Arguments: -Dhttp.port=9001 -Dhttps.port=9443 -Djsse.enableSNIExtension=false -Dhazelcast.config=conf/hazelcast-dev.xml -Dlogger.file=conf/logback-dev.xml -Dconfig.file=conf/passwords/local-dev.conf

JVM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13, mixed mode)
Java: version 1.8.0_121, vendor Oracle Corporation
Java Home: /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre
JVM Flags: <none>

Heap dump on OOME: disabled

JVM arguments:

-Xms1024m
-Xmx1024m
-XX:ReservedCodeCacheSize=128m
-XX:MaxMetaspaceSize=256m
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005

Here's a bit more detail from VisualVM on where the time goes:

CPU sampling

Is 80% CPU usage -- and fans running most of the time -- reasonable while sbt is idling? Seems really high. Any strategies for bringing it down?

PS: When sbt is just at the command prompt (not watching for file changes) Activity Monitor shows about 5% CPU usage.

PPS: I normally have concurrentRestrictions in Global += Tags.limit(Tags.Test, 4) in my build file to prevent too many concurrent database connections during tests. I'm not sure if this actually does what I think it does. The stats, above, are with that line commented out. When I restore it Activity Monitor still reports ~80% CPU usage but in the CPU samples idleAwaitWork doesn't show up at all and ConcurrentRestrictions$$anon$4.take takes the top spot with SourceModificationWatch$.watch right behind it.

Upvotes: 8

Views: 1078

Answers (1)

Eugene Yokota
Eugene Yokota

Reputation: 95604

Assuming you're using sbt 1, this might be due to https://github.com/sbt/sbt/issues/3860 as pointed out by Waldemar Wosiński in comment.

Since we've adopted Close Watch, the problem should now be fixed. Please try sbt 1.1.6 or later and see if the problem still persists.

Upvotes: 1

Related Questions