Question

我使用Camel的Jetty组件通过Akka（端点）实现了一个Web服务，它通过以下设置将收到的消息转发给一个actor池：

   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内存 - 像OS这样的CentOS）之后，由于OutOfMemory（不是JVM OOM），操作系统（oom-killer）会导致进程崩溃。大约30个电话（无论通话频率如何）。

在本地分析应用程序时，如果存在任何内存泄漏，则不会显示任何重大内存泄漏。由于一些困难，我无法在远程机器上执行适当的分析但是监视“顶部”输出，我观察到一些有趣的内容，即应用程序初始化后可用内存大约400mb，之后它在380mb到400mb之间反弹非常自然（gc等）。但有趣的是，在收到第30个左右的电话后，它突然从那里变为5mb的免费记忆和热潮，它被杀死了。 oom-killer登录/ var / log / messages验证由于内存/可用交换不足而导致操作系统完成此操作。

现在这不完全与Akka相关，但我终于决定在经过3天无望的摔跤之后，我应该向你们寻求一些建议。

感谢任何线索。

Answer 1

我观察到，当创建大量小对象时，应立即对其进行垃圾回收，Java进程将被终止。也许是因为在GC回收临时对象之前达到了内存限制。

尝试使用并发标记和清除垃圾收集器运行它：

java -XX:+UseConcMarkSweepGC

Answer 2

我的一般观察是JVM使用了Java堆之外的大量内存。我不知道究竟是什么，但只能推测它可能使用普通的C堆进行编译或编译代码存储或其他permgen的东西或诸如此类的东西。不管怎样，我发现很难控制它的使用。

除非您非常关注磁盘存储，否则您可能只想创建一个GB或两个GB的交换文件，以便JVM有一些溢出的地方。根据我的经验，它在Java堆外部使用的内存无论如何都不会经常被引用，并且可以安全地交换出来而不会导致太多的I / O.

JVM进程被OS杀死

2 个答案: