java - Google App 引擎 - 了解实例如何启动以及需要什么内存 (Java)

Question

我试图准确了解应用程序引擎如何针对新请求启动新实例。我已经使用应用程序引擎工作了一段时间，但我不再知道哪里我不知道文档(没有完成我的“作业”)以及哪里存在错误/调度程序问题。

我刚刚尝试创建一个新的 Web 应用程序项目(Java - Eclipse)，其中仅包含“Hello world”servlet。然后我将其部署到测试版本的云控制台应用程序中，以查看首次加载时需要多少内存。

有 2 个发现我不明白:

1. 在我调用测试 servlet 后，实例已经消耗了 120Mb。为什么需要这么多内存？这是实例的java jvm的内存，还是整个容器的内存？
2. 每次调用 servlet 时都会启动一个新实例。我调用(随后，不是并行)它 10 次，我有 9 个实例(每个实例 1 个请求)，其中一个实例处理了 2 个请求。之后，大多数请求都由现有实例处理，但其中一些请求再次生成新实例。为什么？ (每次测试(调用 servlet)之后，我都会等待接收响应，并在发出新请求之前等待几秒钟)

我的 appengine-web.xml 文件是:

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>[...]</application>
  <version>test-memory</version>

  <!--
    Allows App Engine to send multiple requests to one instance in parallel:
  -->
  <threadsafe>true</threadsafe>

  <!-- Configure java.util.logging -->
  <system-properties>
    <property name="java.util.logging.config.file" value="WEB-INF/logging.properties"/>
  </system-properties>

    <sessions-enabled>true</sessions-enabled>

    <precompilation-enabled>true</precompilation-enabled>

    <instance-class>F1</instance-class>
      <automatic-scaling>
        <min-idle-instances>1</min-idle-instances>
        <max-idle-instances>2</max-idle-instances>
        <min-pending-latency>350ms</min-pending-latency>
        <max-pending-latency>automatic</max-pending-latency>

      </automatic-scaling>



</appengine-web-app>

Servlet 代码:

public class TestAppEngineMemServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}

我使用 Java 1.9.42 SDK 进行了测试，并使用 Java 8 进行本地开发，Java 编译器合规性级别为 7(如果有的话)，具有 F1 或 F2 实例类的标准环境。

请指教，谢谢。

Answer 1

生成新实例的机制实际上非常简单。您有待处理的延迟，这是请求在由可用实例处理之前位于队列中的时间。

如果挂起的延迟超过您指定的阈值，将启动一个新实例。

现在您应该感兴趣的是每次启动新实例时都会发生的预热请求，因此需要更长的时间。

假设您的测试是这样的

t+0s: request #1 (causes warmup since there is no instance yet)
t+1s: request #2 (causes warmup since the first instance is not there yet)
t+2s: ... you get where this is going ...
t+8s: the first instance is now ready to serve and requests are being processed
t+9s: the second instance is now ready to serve
t+xs: request #x (does not cause warmup requests because there are enough instances)
t+xs: instances slowly spin down because there isn't enough traffic to justify its existence 

您在这里看到的是，您的请求不必并行才能导致看似愚蠢的行为。

至于内存(这确实应该是一个单独的问题):你看到的是容器/虚拟机使用的内存。这大约是 Java VM 的内存+可能是容纳它的 docker 镜像环境的一些样板文件。 Java 为运行时分配内存，因此与 C/C++ 相比，它总是相对较高(您可以使用 -Xms/-Xmx 参数在本地指定)

所以内存不是必需的，而是分配给JVM使用的。内存量可能会随着时间的推移而增加，但是当 JVM 中释放内存时，它不一定会立即返回到系统。