【发布时间】:2023-03-11 01:25:01
【问题描述】:
在我看来,SBT 只是在监视文件更改时占用了过多的 CPU 时间。我知道this 的帖子,但是那里的作者将IDE cpu 时间与SBT cpu 时间混淆了;我没有运行 IDE。
我正在使用 Scala 开发一个 Play 项目,其中包含大约 370 个 scala 文件,分为 5 个模块。
在我的 MacBook Pro(2012 年中)上使用 ~run 运行 sbt 会消耗大约 70-90% 的 CPU。我没有运行 IDE,我没有编辑任何文件,没有浏览器访问服务器......根据 Activity Monitor,仅使用 ~run 空闲(并查看文件系统)会占用 70-90% 的 CPU。
看着它闲置了一段时间后,我启动了 VisualVM;它显示了自己和另一个 JVM 进程:
xsbt 进程的详细信息(每个 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 参数:
-Xms1024m
-Xmx1024m
-XX:ReservedCodeCacheSize=128m
-XX:MaxMetaspaceSize=256m
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
下面是 VisualVM 关于时间去向的更多细节:
在 sbt 空闲时,80% 的 CPU 使用率——以及大部分时间都在运行的风扇——是否合理?好像真的很高有什么策略可以降低它?
PS:当 sbt 只是在命令提示符下(不监视文件更改)时,活动监视器显示大约 5% 的 CPU 使用率。
PPS:我的构建文件中通常有concurrentRestrictions in Global += Tags.limit(Tags.Test, 4),以防止测试期间并发数据库连接过多。我不确定这是否真的像我认为的那样。上面的统计数据已注释掉该行。当我恢复它时,Activity Monitor 仍然报告约 80% 的 CPU 使用率,但在 CPU 样本中,idleAwaitWork 根本没有出现,ConcurrentRestrictions$$anon$4.take 位居榜首,SourceModificationWatch$.watch 紧随其后。
【问题讨论】:
-
这个问题可能是相关的:github.com/sbt/sbt/issues/3860
标签: performance scala playframework sbt