Потоки планировщика 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-битную операционную систему или нет.