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"我們增加了相對於 CPU 數量的會話數量（48 個並發執行緒對 32 個 CPU），死鎖消失了。雖然改變並發執行緒在響應時間方面有所幫助，但在所有這些測試期間，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 分鐘內完成。
我們已經從各自的管理員那裡獲得了系統、網路和數據庫報告，並且它們沒有被徵稅；甚至通過伺服器監視器、top、prstat、執行 sar 報告等查看伺服器統計資訊。所以我們認為這是 CF 伺服器或 JVM 的問題。
對於我們還可以嘗試什麼，我已經沒有想法了。免責聲明：我不是 CF 開發人員或管理員。我只是在執行負載測試，分析報告、執行緒等，並與開發和管理團隊共享結果，並嘗試下一個更改，等等。到目前為止還沒有骰子。
有沒有人遇到過類似的事情？您是如何進行診斷和故障排除的？歡迎所有的想法和指點。
感謝您的時間！
公里
感謝 Mark 和 Adam 花時間查看我的問題並提出您的建議。此特定問題已得到解決。顯然，我們的新伺服器是建立在帶有“損壞的 CF”的舊伺服器之上的——不管這意味著什麼。它已經重新重建，性能不再是問題。
公里
當您鎖定應用程序範圍（名稱或“範圍”鎖定）時，您實際上是在“序列化”應用程序變數。所以這本身就是一個問題….應用程序變數應該被鎖定並寫入一次，然後隨意讀取（最好安全地沒有鎖，因為它們不會改變）。無論如何，這可能是一個紅鯡魚。當您鎖定應用程序範圍並始終訪問您的鎖時，您自然會在日誌中得到與它相關的內容（因為那裡發生了很多事情）。
這是我最好的猜測
檢查“coldfusion 監視器”並確保（雙、三、四）“記憶體分析”未啟用。事實上，對於您的負載測試，請確保未啟用跟踪和監控——我什至會關閉指標。您上面的程式碼段讓我認為記憶體跟踪已打開，而您只是超出了伺服器。發生這種情況是因為必須不斷自省堆以進行更改 - 非常昂貴。記憶體跟踪只應在您進行基線時啟用一小段時間。
32 個 CPU 和 48 個 sim。請求……這是很多CPU能力。如果您使用 JRUN，請確保 Jrun 執行緒設置在足夠遠的北方，以便 Jrun 有一些控制執行緒可以使用。
檢查 bin 目錄中的熱點錯誤 - 以“hs_errpidXXX.log”（或類似內容）開頭的錯誤。如果您看到它們，堆棧可能會為您提供一些線索 - 但通常是諸如 out of mem 錯誤或 3rd 方 CFX 或本機 java 程式碼之類的東西，它們向 hotsport 編譯器拋出未處理的異常。
最後，仔細檢查您的客戶端變數。有時，當您不“認為”您正在使用它們時，您正在使用它們。如果您是，它們將儲存在 Solaris 伺服器上的文件中，並且在負載下肯定會導致問題 - 特別是在清除期間附加或鎖定文件時。查看這篇文章了解更多資訊：
http://www.coldfusionmuse.com/index.cfm/2009/10/27/registry.bad.datasource.good
目前想到的就是這些……如果你想讓我在星期一（正式地）仔細看一下，請告訴我，我們可以聊聊。