У нас есть приложение 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», которые были привязаны к «приложению». Затем мы (команда разработчиков) изменили их, чтобы они были ограничены «именем».
После дополнительных нагрузочных тестов блокировок и тупиков нет, но теперь приложение обновляется через 7-10 минут.
Мы получили отчеты о системе, сети и БД от соответствующих администраторов, и они не облагаются налогом; даже смотрел статистику сервера с помощью server monitor, top, prstat, запускал отчеты sar и т. д. Поэтому мы считаем, что это проблема с сервером CF или, возможно, с JVM.
У меня заканчиваются идеи, что еще мы можем попробовать. Отказ от ответственности: я не разработчик CF или администратор. Я просто запускаю нагрузочный тест, анализирую отчеты, потоки и т. Д., Делюсь результатами с командами разработчиков и администраторов, пробую следующее изменение и т. Д. Пока никаких кубиков.
Кто-нибудь сталкивался с чем-то подобным? Как вы подходили к диагностике и устранению неполадок? Все мысли и указатели приветствуются.
Спасибо за уделенное время!
Км
Когда вы блокируете область приложения (либо имя, либо блокировку "области"), вы по существу "сериализируете" переменные приложения. Так что это само по себе проблема .... переменные приложения должны быть заблокированы и записаны один раз, а затем прочитаны по желанию (желательно и безопасно без блокировок, поскольку они не меняются). В любом случае это может быть отвлекающим маневром. когда вы блокируете область приложения и все время получаете доступ к своим блокировкам, вы, естественно, получаете вещи, связанные с этим, в журнале (поскольку там так много всего происходит).
Вот мои лучшие догадки
Проверьте «монитор холодного слияния» и убедитесь (двойной, тройной, четырехмерный), что «профилирование памяти» не включено. Фактически, для вашего нагрузочного теста убедитесь, что отслеживание и мониторинг не включены - и я бы даже отключил метрики. Ваш фрагмент выше заставляет меня думать, что отслеживание памяти включено, и вы просто переполняете сервер. Это происходит потому, что кучу нужно постоянно проверять на предмет изменений - очень дорого. Отслеживание памяти следует включать только на короткое время при определении базовых показателей.
32 процессора и 48 сим. запросы .... это большая мощность процессора. Если вы используете JRUN, убедитесь, что потоки Jrun установлены достаточно далеко к северу от этого, чтобы Jrun имел некоторые управляющие потоки для работы.
Проверьте каталог bin на наличие ошибок горячих точек - ошибок, начинающихся с "hs_errpidXXX.log" (или чего-то подобного). Если вы их видите, стек может дать вам некоторые подсказки, но обычно это такие вещи, как ошибки вне памяти или сторонний CFX или собственный Java-код, который выдает необработанные исключения в компилятор hotsport.
Наконец, дважды проверьте свои клиентские vars. Иногда вы используете их, когда вам не кажется, что вы их используете. В противном случае они будут храниться в файле на вашем сервере Solaris, и это определенно вызовет проблемы при загрузке, особенно если файл добавляется или блокируется во время очистки. Прочтите этот пост для получения дополнительной информации:
http://www.coldfusionmuse.com/index.cfm/2009/10/27/registry.bad.datasource.good
Это все, что приходит в голову в данный момент ... если вы хотите, чтобы я рассмотрел это поближе в понедельник (на официальной основе), дайте мне знать, и мы можем поговорить об этом.
Спасибо, Марк и Адам, за то, что нашли время просмотреть мой вопрос и ваши предложения. Эта конкретная проблема была решена. Очевидно, наш новый сервер был построен на базе старого сервера с «поврежденным CF» - что бы это ни значило. С тех пор он был перестроен заново, и производительность больше не является проблемой.
Км