Question

我已使用Elastic Beanstalk在AWS服务器中部署了dockerized微服务，该服务使用Akka-HTTP（https://github.com/theiterators/akka-http-microservice）和Scala编写。

我为每个docker分配了512mb的内存大小和性能问题。我注意到当服务器获得更多请求（例如20％，23％，45％......）时，CPU使用率会增加。取决于负载，然后它自动降至正常状态（0.88％）。但是对于每个请求，内存使用量一直在增加，即使CPU使用率达到正常阶段并且达到100％并且docker被自身杀死并再次重新启动，它也无法释放未使用的内存。

我还在EB中启用了自动缩放功能来处理大量请求。因此，只有在运行实例的CPU使用率达到最大值后，才会创建另一个重复实例。

如果内存使用达到最大限制（即512mb中的500mb），如何设置自动缩放以创建另一个实例？

请尽快为我们提供解决方案/方法，因为这对我们来说是一个非常关键的问题？

Answer 1

CloudWatch本身并未报告内存统计信息。但是亚马逊提供了一些脚本（通常简称为＃34;用于Linux的CloudWatch监控脚本），它们可以将统计数据导入CloudWatch，以便您可以使用这些指标来构建扩展策略。

Elastic Beanstalk文档提供了有关在http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-cw.html上在Linux平台上安装脚本的一些信息。

然而，这将伴随另一个警告，即您无法使用本机Docker部署JSON，因为它不会选择.ebextensions文件夹（请参阅Where to put ebextensions config in AWS Elastic Beanstalk Docker deploy with dockerrun source bundle?）。这里的解决方案是创建一个包含JSON文件和.ebextensions文件夹的应用程序zip，并将其用作部署工件。

还有一件事我不清楚，那就是如果可以在配置下选择这些指标 - ＆gt;缩放应用程序的部分。您可能需要创建另一个.ebextensions配置文件来设置自定义指标，例如：

option_settings:
  aws:elasticbeanstalk:customoption:
    BreachDuration: 3
    LowerBreachScaleIncrement: -1
    MeasureName: MemoryUtilization
    Period: 60
    Statistic: Average
    Threshold: 90
    UpperBreachScaleIncrement: 2

现在，即使这样做，如果应用程序在缩放和加载失败后不会降低其内存使用量，那么扩展策略将继续触发并最终达到最大实例。

我首先看看您是否可以获取JVM的一些垃圾收集统计信息，并且可能会调整JVM以更频繁地进行垃圾收集，以帮助在应用程序负载下降后更快地降低内存。

一旦我的docker达到其最大内存限制，AWS EB就应该创建新实例

1 个答案: