Question

我已经在开发盒上运行了CF10，Windows 7,64位。每隔一分钟左右，CF10的CPU使用率将在大约20秒内上升到100％并再次下降。这很规律。

我发现很难诊断出这个问题。我已经看到过关于客户变量清除，记录，监控和各种事情的讨论 - 但是我已经把这些全部转为无效。

使用VisualVM，我成功地将问题跟踪到了调度程序＆＃39;线程。我有5个处于等待状态。每个都会定期运行，从而大大提高CPU的性能。采取线程转储，似乎所有这些线程都在调用java.io.WinNTFileSystem.getBooleanAttributes - 我已经看过几次提到的可能存在问题。

更新：最近我在另一个应用上玩过onSessionEnd，发现scheduler-x个主题似乎是ColdFusion内部的 - 我的onSessionEnd任务似乎总是运行在其中一个主题中。

查看临时文件夹，我可以看到已经制作了很多EH Cache文件夹，我认为这些文件夹与查询缓存有关。我运行的应用程序相当广泛地使用它。我认为清除临时文件夹可能会提高性能，但它没有任何效果。

值得注意的是，如果我在没有实际调用任何应用程序的情况下启动CF服务，则不会出现问题。这可能表明问题出在应用程序本身，但它们不会在生产中造成任何问题 - 仅限于此框。也没有设置任何计划任务。

以下是导致高CPU的一个线程的示例。我很感激在诊断这个线程正在做什么以及为什么这么做以及如何阻止它使用这么多资源方面有任何帮助。

"scheduler-2" - Thread t@84
   java.lang.Thread.State: RUNNABLE
    at java.io.WinNTFileSystem.getBooleanAttributes(Native Method)
    at java.io.File.isDirectory(File.java:849)
    at coldfusion.watch.Watcher.accept(Watcher.java:352)
    at java.io.File.listFiles(File.java:1252)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:386)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:397)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:397)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:397)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:397)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:397)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:397)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:397)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:397)
    at coldfusion.watch.Watcher.getFiles(Watcher.java:397)
    at coldfusion.watch.Watcher.checkWatchedDirectories(Watcher.java:166)
    at coldfusion.watch.Watcher.run(Watcher.java:216)
    at coldfusion.scheduling.ThreadPool.run(ThreadPool.java:211)
    at coldfusion.scheduling.WorkerThread.run(WorkerThread.java:71)

我的环境：

Win 7 64位
CF10 Update 12
JDK 1.8.0_11

在多个版本的JVM上出现此问题 - 此版本目前用于使监控可用。

我的java设置：

最小堆大小：512mb
最大堆大小：1024mb

-server -XX：MaxPermSize = 512m -XX：+ UseParallelGC -Xbatch -Dcoldfusion.home = {application.home} -Dcoldfusion.rootDir = {application.home} -Dcoldfusion.libPath = {application.home} / lib -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER = true -Dcoldfusion.jsafe.defaultalgo = FIPS186Random -XX：+ HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote.port = 8701 -Dcom.sun.management.jmxremote.ssl = false -Dcom。 sun.management.jmxremote.authenticate =假

如果我说我理解了所有这些设置的作用，我会撒谎！对不起，如果您认为所有CF开发人员都应该是Java应用程序堆栈专家的那些人之一。我不是。任何帮助，非常感谢。 ;）

Answer 1

使用FusionReactor 6，我今天能够为我们解决这个问题。我们使用this.javaSettings来加载java类文件。来自WatchInterval的{{1}}使用指定观看号码的this.javaSettings。在我们的例子中，我把它降低到一秒钟。

我是如何解决的：我在FusionReactor中设置了一个断点，可以看到它一直在扫描我在DirectoryWatcher中指定的目录上方的目录。此目录包含足够的文件和子文件夹，看起来一个this.javasettings在创建下一个文件之前无法完成。如果ColdFusion只是粘在子文件夹上，我在DirectoryWatcher中指定，那就不会有问题了。

示例：

this.javaSettings

在上面的例子中，lib只有5个文件。然而，“外部”充满了东西。在断点中，它通常在“外部”中查看内容。

Answer 2

您是否有使用CFFILE标记运行的计划任务？他们往往是资源匮乏。将这些旋转到自己的线程可能有助于CPU峰值。

另一个想法：

查看JVM，

•Min heap size: 512mb
•Max heap size: 1024mb

这些建立了java虚拟机可用的最小和最大内存

-server -XX:MaxPermSize=512m

这是专用于java永久内存生成的内存量。

您已经将一半的JVM分配内存专用于永久代，请尝试将最大堆大小增加到2048mb。并重新启动ColdFusion服务。根据您是否运行64位操作系统，它可能会更高。

ColdFusion调度程序线程吃CPU

2 个答案: