我們有一個Java ERP類型的應用程序。服務器和客戶端之間的通信通過RMI進行。在高峯時段，最多可以有250個用戶登錄，其中約20個用戶正在同時工作。這意味着在高峯時段的任何時間都有大約20個線程在線。 服務器可以運行數小時而沒有任何問題，但突然間的響應時間會越來越快。響應時間可以在幾分鐘內完成。如何確定爲什麼Java應用程序很慢
我們使用Sun的JDK 1.6.0_16在Windows 2008 R2上運行。我們一直在使用perfmon和Process Explorer來查看正在發生的事情。唯一讓我們覺得奇怪的是，當服務器開始工作時，java.exe進程打開的句柄數量大約爲3500.我並不是說這是一個問題。
我只是好奇，如果有一些指導原則，我應該按照指出問題。我應該使用哪些工具？ ....
聽起來像垃圾收集不能跟上，並開始「停止世界」收集由於某種原因。
在啓動時附加JDK中的jvisualvm，並在性能下降時查看收集的數據。
我在今天的啓動腳本中添加了-verbose：gc。如果GC是問題，我會明天再見。 – kovica 2010-08-24 16:24:56
你發現了什麼？ – 2011-11-10 21:57:15
您可以訪問此應用程序的日誌配置嗎？
如果可以，應該將日誌級別更改爲「DEBUG」。跟蹤請求的調試日誌可以爲您提供有關爭用點的有用信息。
如果不能，分析器工具可以幫助您：
如果應用程序已經用JMX控制poi nts，你可以插入一個JMX查看器來獲取信息...
如果你想強調應用程序觸發問題（如果你想驗證它是否是一個收費問題），你可以使用壓力工具，如JMeter
可悲的是我們沒有使用log4j或任何日誌框架。服務器現在大約有10年曆史了，要改變它會很昂貴。 如果緩慢會在測試系統上顯示出來，那麼使用profiler會很好。由於這是一個生產系統，我無法在那裏玩。 JMeter不支持通過RMI進行測試。 – kovica 2010-08-24 16:28:14
你所描述的問題很典型，但也很普遍。原因可能從內存泄漏，資源爭用等等到糟糕的GC策略以及堆/ PermGen空間分配。爲了指出應用程序的確切問題，您需要對其進行概要分析（我知道諸如Yourkit和JProfiler之類的工具）。如果你明智地分析你的應用程序，只有一些應用程序週期會揭示問題，否則分析本身不是很容易。
在類似的情況下，我自己編寫了一個簡單的剖析代碼。基本上我使用了一個ThreadLocal，其中有一個「StopWatch」（基於LinkedHashMap），然後我將如下代碼插入到應用程序的各個點中：watch.time("OperationX");
然後在線程完成任務後，請撥打電話watch.logTime();，該班會寫下如下所示的日誌：[DEBUG] StopWatch time:Stuff=0, AnotherEvent=102, OperationX=150
之後，我編寫了一個簡單的解析器，可以從此日誌（每個代碼路徑）生成CSV。你可以做的最好的事情是創建一個直方圖（可以使用Excel輕鬆完成）。平均值，中等和偶數模式都可以欺騙你。我強烈建議創建一個直方圖。
與此直方圖一起，您可以使用平均/中等/模式（它代表最佳數據，您可以從直方圖中確定此數據）創建線圖。
通過這種方式，您可以百分之百地確切地知道什麼操作需要花費時間。如果你不能確定罪魁禍首，二進制搜索是你的朋友（罰款事件）。
可能聽起來真的很原始，但起作用。另外，如果您從中創建一個庫，則可以在任何項目中使用它。這也很酷，因爲你可以很容易地在生產中打開它。
除了其他人提到的GC以外，嘗試在減速過程中每隔5-10秒嘗試一次線程轉儲，持續約30秒。可能會出現數據庫調用，Web服務或其他依賴項變慢的情況。如果您仔細觀察胎面垃圾箱，您將能夠看到看起來不會移動的線，並且您可以通過這種方式縮小罪魁禍首。
從GC的角度來看，您是否在這些時間監控您的CPU使用情況？如果GC頻繁運行，您將看到整體CPU使用率的跳躍。
如果只有這是一個Solaris盒子，prstat會是你的朋友。
對於像這樣的急性問題，快速jstack <pid>應該快速指出問題區域。可能不需要讓所有人都喜歡它。
如果我不得不猜測，我會說熱點跳進來，並嚴格優化了一些寫得不好的代碼。 Netbeans開始停止使用新創建的對象來緩存文件數據的地方WeakHashMap。經過優化後，可以在添加後直接從地圖中刪除條目。很明顯，如果緩存被依賴，那麼很多文件活動就是如此。您可能不會看到驅動器亮起，因爲它將全部由操作系統緩存。
什麼是內存使用情況 - 真實還是虛擬 - 當你出現放緩時會怎麼做？ – 2010-08-24 17:32:41