性能测试分析案例-定位应用容器化后很慢

环境准备

预先安装 docker、curl、jq、pidstat 等工具，如 apt install docker.io curl jq sysstat

操作和分析

执行下面的命令，启动 Tomcat 应用，并监听 8080 端口。

docker run --name tomcat --cpus 0.1 -m 512M -p 8080:8080 -itd feisky/tomcat:8

终端二中使用 curl，访问 Tomcat 监听的 8080 端口

curl localhost:8080

在终端一中，执行下面的命令，查看容器的状态：

docker ps -a

容器处于 Exited 状态，说明是第一种情况，容器已经退出。不过为什么会这样呢？
可以调用 Docker 的 API，查询容器的状态、退出码以及错误信息，然后确定容器退出的原因。这些可以通过 docker inspect 命令来完成，比如，你可以继续执行下面的命令，通过 -f 选项设置只输出容器的状态：

 docker inspect tomcat -f '{{json .State}}' | jq

容器已经处于 exited 状态，OOMKilled 是 true，ExitCode 是 137。这其中，OOMKilled 表示容器被 OOM 杀死了。
OOM 表示内存不足时，某些应用会被系统杀死。可是，为什么内存会不足呢？我们的应用分配了 256 MB 的内存，而容器启动时，明明通过 -m 选项，设置了 512 MB 的内存，按说应该是足够的。
在终端中执行 dmesg 命令，查看系统日志，并定位 OOM 相关的日志

dmesg

第一，被杀死的是一个 java 进程。从内核调用栈上的 mem_cgroup_out_of_memory 可以看出，它是因为超过 cgroup 的内存限制，而被 OOM 杀死的。
第二，java 进程是在容器内运行的，而容器内存的使用量和限制都是 512M（524288kB）。目前使用量已经达到了限制，所以会导致 OOM。第三，被杀死的进程，PID 为 12805，虚拟内存为 4.3G（total-vm:4613208kB），匿名内存为 505M（anon-rss:517316kB），页内存为 19M（20168kB）。换句话说，匿名内存是主要的内存占用。而且，匿名内存加上页内存，总共是 524M，已经超过了 512M 的限制。
为什么 Tomcat 会申请这么多的堆内存呢？要知道，Tomcat 是基于 Java 开发的，所以应该不难想到，这很可能是 JVM 堆内存配置的问题。
JVM 根据系统的内存总量，来自动管理堆内存，不明确配置的话，堆内存的默认限制是物理内存的四分之一。不过，前面我们已经限制了容器内存为 512 M，java 的堆内存到底是多少呢？
执行下面的命令，重新启动 tomcat 容器，并调用 java 命令行来查看堆内存大小：

docker rm -f tomcat
docker run --name tomcat --cpus 0.1 -m 512M -p 8080:8080 -itd feisky/tomcat:8

初始堆内存的大小（InitialHeapSize）是 59MB，而最大堆内存则是 0.9GB，这可比容器限制的 512 MB 大多了。
之所以会这么大，其实是因为，容器内部看不到 Docker 为它设置的内存限制。虽然在启动容器时，我们通过 -m 512M 选项，给容器设置了 512M 的内存限制。但实际上，从容器内部看到的限制，却并不是 512M。 JVM 正确配置内存限制为 512M 就可以了。

docker run --name tomcat --cpus 0.1 -m 512M -e JAVA_OPTS='-Xmx512m -Xms512m' -p 8080:8080 -itd feisky/tomcat:8