JVM進程由OS

打死我實現了用駱駝的碼頭成分通過阿卡（端點），它收到的郵件轉發給演員池的設置Web服務：JVM進程由OS

def receive = _route() 
    def lowerBound = 5 
    def upperBound = 20 
    def rampupRate = 0.1 
    def partialFill = true 
    def selectionCount = 1 
    def instance() = Actor.actorOf[Processor]

和處理器是一個類，處理收到的消息並回復該過程的結果。該應用程序在我的本地機器上一直正常工作，但是在將它部署到EC2微型實例（512m內存 - 如操作系統CentOS）之後，由於OutOfMemory（而不是JVM OOM），操作系統（OOM殺手）會殺死進程30個電話左右（不管電話的頻率）。

本地分析應用程序不會顯示任何重大的內存泄漏（如果完全存在）。由於一些困難，我無法在遠程機器上執行適當的分析，但監視「頂級」輸出，我觀察到一些有趣的事情，即在應用程序初始化後可用的可用內存保持在400mb左右，之後它在380mb到400mb之間反彈，這似乎很自然（gc等）。但有意思的是，在接到第30個電話後，它突然從那裏跳到5mb的空閒內存和繁榮，它被殺了。 oom-killer登錄/ var/log/messages會驗證這是否由於缺乏內存/空閒交換而由OS完成。

現在這不完全是Akka相關的，但我終於決定我應該從你們那裏尋求一些建議，經過3天無望的摔跤。

感謝您的任何線索。

來源

2011-08-23 parsa

您是否嘗試過減少JVM堆大小？ –

是的，我設置了一個64米硬限制，但奇怪的是仍然在達到JVM限制之前被殺死。也許我應該嘗試較低的金額？ – parsa

我觀察到，當很多小對象被創建時，應立即垃圾回收，Java進程被終止。也許是因爲在GC回收對象之前已達到內存限制。

嘗試使用併發標記運行它和掃垃圾收集器：

java -XX:+UseConcMarkSweepGC

來源

2014-02-01 19:34:24 tuxdna

我總的看法是，JVM使用了大量的超越Java堆內存。我不知道究竟是什麼，但只能推測它可能使用普通的C堆進行編譯或編譯代碼存儲或其他permgen的東西或什麼。無論如何，我發現很難控制它的使用。

除非您非常關注磁盤存儲，否則您可能只需創建一個GB或兩個GB的交換文件，以便JVM有一定的溢出位置。根據我的經驗，它在Java堆外部使用的內存不會經常被引用，並且可以安全地換出，而不會導致太多的I/O。

來源

2014-02-01 19:39:12 Dolda2000

回答

相關問題