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

Question

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

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

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

UPDATE: Недавно я играл с onSessionEnd на другом приложении, и обнаружил, что scheduler-x нитей кажутся внутренней для ColdFusion - мое onSessionEnd задача всегда, кажется, работает в одной из этих нитей.

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

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

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

"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.jmxrem ote.port = 8701 -Dcom.sun.management.jmxremote.ssl = false -Dcom.sun.management.jmxremote.authenticate = false

Я бы солгал, если бы сказал, что понял, что все эти настройки делают! Извините, если вы один из тех людей, которые считают, что все разработчики CF должны быть экспертами в Java-приложении. Не я. Любая помощь, очень ценится. ;)

Answer 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 файлов. Однако «внешние» загружаются материалом. В точке останова он обычно смотрел на вещи в «внешних».

Answer 2

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

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

глядя на JVM,

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

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

-server -XX:MaxPermSize=512m 

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

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