Применение Coldfusion 8 падает при большой нагрузке
У нас есть приложение CF8, которое работает в течение 20-25 минут, а затем падает при большой нагрузке ~ 1200 пользователей. Эта нагрузка генерируется нашим инструментом нагрузочного тестирования: 1200 пользователей разгоняются за 5 минут (примерное поведение наших пользователей) и работают в течение часа.
У нас есть это приложение на Solaris 10, Apache 2, JRun 4 и Oracle 10g. Java версия 1.6.
Во время начальных нагрузочных тестов дампы потоков указывали на взаимные блокировки монитора, указывающие на сеансы.
"jrpp-173":
waiting to lock monitor 0x019fdc60 (object 0x6b893530, a java.util.Hashtable),
which is held by "scheduler-1"
"scheduler-1":
waiting to lock monitor 0x026c3ce0 (object 0x6abe2f20, a coldfusion.monitor.memory.SessionMemoryMonitor$TopMemoryUsedSessions),
which is held by "jrpp-167"
"jrpp-167":
waiting to lock monitor 0x019fdc60 (object 0x6b893530, a java.util.Hashtable),
which is held by "scheduler-1"
Мы увеличили количество сессий относительно количества процессоров (48 одновременных потоков против 32 процессоров), и тупик исчез. В то время как изменение одновременных потоков немного помогло с точки зрения времени отклика, сервер CF все еще работал в течение 20-25 минут во время всех этих тестов.
Мы запустили больше дампов потока и увидели поток, блокирующий монитор, например:
"jrpp-475" prio=3 tid=0x02230800 nid=0x2c5 runnable [0x4397d000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:347)
at java.util.HashMap.containsKey(HashMap.java:335)
at java.util.HashSet.contains(HashSet.java:184)
at coldfusion.monitor.memory.MemoryTracker.onAddObject(MemoryTracker.java:124)
at coldfusion.monitor.memory.MemoryTrackerProxy.onReplaceValue(MemoryTrackerProxy.java:598)
at coldfusion.monitor.memory.MemoryTrackerProxy.onPut(MemoryTrackerProxy.java:510)
at coldfusion.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:250)
at coldfusion.util.FastHashtable.put(FastHashtable.java:43)
- locked <0x6f7e1a78> (a coldfusion.runtime.Struct)
at coldfusion.runtime.CfJspPage._arrayset(CfJspPage.java:1027)
at coldfusion.runtime.CfJspPage._arraySetAt(CfJspPage.java:2117)
at cfvalidation2ecfc1052964961$funcSETUSERAUDITDATA.runFunction(/app/docs/apply/cfcs/validation.cfc:377)
Как вы видите в последней строке выше, было несколько ссылок CFM и CFC, и строки имеют теги cflock, которые были ограничены областью "application". Затем мы (команда разработчиков) изменили их, чтобы определить их как "имя".
После дополнительных нагрузочных тестов блокировка не происходит и блокировок нет, но теперь аппликации за 7-10 минут.
Мы получили отчеты о системе, сети и БД от соответствующих администраторов, и они не облагаются налогом; даже смотрел статистику сервера с помощью монитора сервера, top, prstat, отчетов sar и т. д. Поэтому мы считаем, что это проблема с сервером CF или, возможно, с JVM.
У меня заканчиваются идеи относительно того, что еще мы можем попробовать. Отказ от ответственности: я не разработчик CF или администратор. Я просто запускаю нагрузочное тестирование, анализирую отчеты, потоки и т. Д., Делюсь результатами с командами разработчиков и администраторов, пробую внести следующие изменения и так далее. Пока что без кубиков.
Кто-нибудь сталкивался с чем-то подобным? Как вы прошли диагностику и устранение неисправностей? Все мысли и указатели приветствуются.
Спасибо за ваше время!
KM
2 ответа
Спасибо, Марк и Адам, за то, что нашли время рассмотреть мой вопрос и за ваши предложения. Эта конкретная проблема была решена. Очевидно, наш новый сервер был построен из старого сервера с "поврежденным CF" - что бы это ни значило. С тех пор он был перестроен заново, и производительность больше не является проблемой.
KM
Когда вы блокируете область приложения (либо имя, либо блокировку "области действия"), вы по существу "сериализуете" переменные приложения. Так что это само по себе является проблемой. Варианты приложения должны быть заблокированы и записаны один раз, а затем прочитаны по желанию (желательно и безопасно без блокировок, поскольку они не меняются). В любом случае, это может быть красная сельдь. Когда вы блокируете область приложения и получаете доступ к своим блокировкам все время, вы, естественно, в журнале обнаруживаете что-то, связанное с ним (поскольку там происходит так много).
Вот мои лучшие догадки
Проверьте "монитор Coldfusion" и убедитесь, что "профилирование памяти" (двойное, тройное, четырехкратное) не включено. Фактически, для вашего нагрузочного теста убедитесь, что отслеживание и мониторинг не включены - и я бы даже отключил метрики. Ваш фрагмент выше заставляет меня думать, что отслеживание памяти включено, и вы просто перегружаете сервер. Это происходит потому, что куча должна постоянно анализироваться на предмет изменений - чрезвычайно дорого. Отслеживание памяти должно быть разрешено только на короткое время, когда вы базовый уровень.
32 процессора и 48 сим. запросы.... это много мощности процессора. Если вы используете JRUN, убедитесь, что потоки Jrun установлены достаточно далеко к северу от того, что Jrun имеет некоторые управляющие потоки для работы.
Проверьте каталог bin на наличие ошибок горячих точек - ошибок, начинающихся с "hs_errpidXXX.log" (или чего-то подобного). Если вы видите их, то стек может дать вам некоторые подсказки - но обычно это такие вещи, как ошибки из памяти, CFX или сторонний код Java, который генерирует необработанные исключения для компилятора hotsport.
Наконец, дважды проверьте ваш клиент. Иногда вы используете их, когда вы не "используете" их. Если это так, они будут сохранены в файле на вашем сервере Solaris, и это определенно вызовет проблему при загрузке, особенно когда файл добавляется или блокируется во время очистки. Проверьте это сообщение для немного больше информации:
http://www.coldfusionmuse.com/index.cfm/2009/10/27/registry.bad.datasource.good
Это все, что приходит в голову на данный момент... если вы хотите, чтобы я посмотрел на это поближе в понедельник (на официальной основе), дайте мне знать, и мы можем поговорить об этом.