我们有一个CF8的应用程序，运行20-25分钟之前，在重负载下崩溃〜1200用户。 这个负载是由我们的负载testing工具产生的：1200用户在5分钟内（大约用户的行为）上升，运行一个小时。
我们在Solaris 10，Apache 2，JRun 4和Oracle 10g上有这个应用程序。 Java版本是1.6。
在初始加载testing期间，线程转储指向监视指向会话的死锁。
"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" 我们增加了相对于CPU数量的会话数量（48个并发线程对32个CPU），并且死锁消失了。 虽然改变同时线程在响应时间方面有所帮助，但在所有这些testing中，CF服务器仍然在20-25分钟内完成。
我们运行了更多的线程转储，并看到一个线程locking显示器，例如：
"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”标签，这些标签被限定在“应用程序”范围内。 我们（开发团队）然后改变他们的范围到一个“名称”。
经过更多的负载testing，没有locking进行，没有死锁，但现在的应用坦克在7-10分钟。
我们已经从各自的pipe理员那里获得了系统，networking和数据库报告，而且他们没有被征税。 甚至用server monitor，top，prstat，run sar reports等来监视服务器状态。所以我们认为这是CF服务器或者JVM的问题。
我想我们还有什么可以尝试的。 免责声明：我不是CF开发人员或pipe理员。 我只是运行负载testing，分析报告，线程等，并与开发团队和pipe理团队分享结果，并尝试下一个更改，等等。 到目前为止没有骰子。
有没有人碰到类似的东西？ 你是如何进行诊断和故障排除的？ 所有的想法和指针欢迎。
感谢您的时间！
KM
当你locking应用程序作用域（名称或“范围”锁）时，本质上是“序列化”应用程序variables。 所以这本身就是一个问题….应用程序variables应该被locking和写入一次，然后随意阅读（最好和安全的没有锁，因为他们没有改变）。 无论如何，这可能是一个红鲱鱼。 当你locking应用范围并且一直访问你的锁的时候，你自然会在日志中得到与它有关的东西（因为在那里发生的事情太多了）。
这是我最好的猜测
检查“Coldfusion监视器”，并确保（双重，三重，四联）的“内存分析”未启用。 事实上，为了进行负载testing，请确保没有启用跟踪和监控 – 我甚至会closures指标。 上面的代码片段让我认为内存跟踪已经启动，而且你只是简单地超越了服务器。 发生这种情况是因为这个堆必须不断地被改变 – 非常昂贵。 内存跟踪只能在基线时短时间启用。
32个CPU和48个SIM卡。 请求….这是很多CPU的权力。 如果您使用JRUN，请确保Jrun线程设置得足够远，Jrun有一些控制线程可以使用。
检查bin目录中的热点错误 – 以“hs_errpidXXX.log”（或类似的东西）开头的错误。 如果你看到他们，堆栈可能会给你一些线索 – 但通常它是像mem out错误或第三方CFX或原生java代码，将未处理的exception扔到热点编译器的东西。
最后，仔细检查你的客户variables。 有时候，当你不使用“thinK”时，你正在使用它们。 如果你是他们将被存储在你的Solaris服务器上的文件，这将肯定会导致负载下的问题 – 特别是当文件被附加到或在清除期间被locking。 看看这个post了解更多信息：
http://www.coldfusionmuse.com/index.cfm/2009/10/27/registry.bad.datasource.good
这就是目前所想到的…如果你希望我在星期一（正式的）让我看看它，让我知道，我们可以聊天。
感谢马克和亚当花时间浏览我的问题和build议。 这个问题已经解决了。 显然，我们的新服务器是build立在一个老旧的服务器上，并且有“腐败的CF” – 无论如何。 现在已经重build了，演出不再是问题了。
KM