Потоки планировщика ColdFusion, использующие процессор

У меня CF10 работает в dev, Windows 7, 64 бит. Периодически, каждую минуту или около того, использование ЦП для CF10 будет увеличиваться до 100% в течение примерно 20 секунд и возвращаться вниз. Это довольно регулярно.

Мне было трудно диагностировать эту проблему. Я видел разговоры о чистках клиентских переменных, регистрации, мониторинге и всех вещах, но я все это отключил безрезультатно.

В VisualVM мне удалось отследить проблему до потоков "scheduler". У меня 5 из них в состоянии ожидания. Периодически каждый из них будет работать, резко увеличивая процессор. Принимая дамп потока, кажется, что все эти потоки вызывают java.io.WinNTFileSystem.getBooleanAttributes - то, что я видел, упоминалось несколько раз как потенциально проблематичное.

ОБНОВЛЕНИЕ: Недавно я играл с onSessionEnd в другом приложении и обнаружил, что потоки scheduler-x кажутся внутренними для ColdFusion. Мои задачи onSessionEnd всегда работают в одном из этих потоки.

Глядя в папку temp, я вижу, что было сделано много папок EH Cache, которые, как я думаю, связаны с кешированием запросов. Приложения, которые у меня работают, используют это довольно широко. Я думал, что очистка папки temp может повысить производительность, но это не повлияло.

Стоит отметить, что если я запускаю службу CF без фактического вызова каких-либо из моих приложений, проблема не возникает. Это может означать, что проблема связана с самими приложениями, однако они не вызывают никаких проблем в производстве - только в этом поле. Также не заданы запланированные задачи.

Ниже приведен пример одного из потоков, вызывающих высокий CPU. Я был бы признателен за любую помощь в диагностике того, что делает этот поток, и почему, а также как потенциально остановить его от использования стольких ресурсов.

"scheduler-2" - Thread [email protected]
   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-bit
Обновление CF10 12
JDK 1.8.0_11

Проблема возникает в нескольких версиях JVM - эта версия в настоящее время используется для обеспечения доступности мониторинга.

Мои настройки java:

Минимальный размер кучи: 512 МБ
Максимальный размер кучи: 1024 МБ

-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-приложениях. Не я. Любая помощь, очень ценится.;)

Ответ 1

Используя FusionReactor 6, я смог решить это для нас сегодня. Мы использовали this.javaSettings для файлов классов java для горячей загрузки. WatchInterval от this.javaSettings использует DirectoryWatcher по указанному номеру часов. В нашем случае я опустил его на одну секунду.

Как я решил: я установил точку останова в FusionReactor и увидел, что он постоянно застревает в каталоге выше того, что я указал в this.javaSettings. В этом каталоге достаточно файлов и подпапок, что похоже, что один DirectoryWatcher не смог закончить до того, как был создан следующий. Если бы ColdFusion просто придерживался подпапки, я указал в this.javaSettings, это не было бы проблемой.

Пример:

This.javaSettings       = {
          loadPaths                 = ["\externals\lib\"]
        , loadColdFusionClassPath   = true
        , reloadOnChange            = true
        , watchInterval             = 1
};

В приведенном выше случае lib имеет всего 5 файлов. Однако "внешние" загружаются материалом. В точке останова он обычно смотрел на вещи в "внешних".

Ответ 2

У вас есть запланированные задачи, которые используют тег CFFILE? Они, как правило, являются ресурсными свиньями. Спиннинг их в свои потоки может помочь с всплеском процессора.

другая мысль:

глядя на JVM,

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

Они устанавливают минимальную и максимальную память, доступные для виртуальной машины Java

-server -XX:MaxPermSize=512m

Это объем памяти, выделяемый для создания постоянной памяти java.

у вас есть половина выделенной памяти JVM, предназначенная для постоянного поколения, попробуйте увеличить максимальный размер кучи до 2048 МБ. и перезапуск службы ColdFusion. Он может быть выше в зависимости от того, используете ли вы 64-битную операционную систему или нет.