一、上节回顾
上一节,我们一起学习了怎么使用动态追踪来观察应用程序和内核的行为。先简单来回顾一下。所谓动态追踪,就是在系统或者应用程序还在正常运行的时候,通过内核中提供的探针,来动态
追踪它们的行为,从而辅助排查出性能问题的瓶颈。
使用动态追踪,便可以在不修改代码也不重启服务的情况下,动态了解应用程序或者内核的行为。这对排查线上的问题、特别是不容易重现的问题尤其有效。
在 Linux 系统中,常见的动态追踪方法包括 ftrace、perf、eBPF/BCC 以及 SystemTap 等。
- 使用 perf 配合火焰图寻找热点函数,是一个比较通用的性能定位方法,在很多场景中都可以使用。
- 如果这仍满足不了你的要求,那么在新版的内核中,eBPF 和 BCC 是最灵活的动态追踪方法。
- 而在旧版本内核,特别是在 RHEL 系统中,由于 eBPF 支持受限,SystemTap 和 ftrace 往往是更好的选择。
在 网络请求延迟变大 的案例中,我带你一起分析了一个网络请求延迟增大的问题。当时我们分析知道,那是由于服务器端开启 TCP 的 Nagle 算法,而客户端却开启了延迟确认所导致的。
其实,除了延迟问题外,网络请求的吞吐量下降,是另一个常见的性能问题。那么,针对这种吞吐量下降问题,我们又该如何进行分析呢?
接下来,我就以最常用的反向代理服务器 Nginx 为例,带你一起看看,如何分析服务吞吐量下降的问题。
二、案例准备
今天的案例需要用到两台虚拟机,还是基于 Ubuntu 18.04,同样适用于其他的 Linux 系统。我使用的案例环境如下所示:
- 机器配置:2 CPU,8GB 内存。
- 预先安装 docker、curl、wrk、perf、FlameGraph 等工具,比如
# 安装必备 docker、curl 和 perf $ apt-get install -y docker.io curl build-essential linux-tools-common # 安装火焰图工具 $ git clone https://github.com/brendangregg/FlameGraph # 安装 wrk $ git clone https://github.com/wg/wrk $ cd wrk && make && sudo cp wrk /usr/local/bin/
这些工具,我们在前面的案例中已经多次使用,这儿就不再重复。你可以打开两个终端,分别登录到这两台虚拟机中,并安装上述工具。
注意,以下所有命令都默认以 root 用户运行,如果你用普通用户身份登陆系统,请运行 sudo su root 命令切换到 root 用户。
到这里,准备工作就完成了。接下来,我们正式进入操作环节。
三、案例分析
我们今天要分析的案例是一个 Nginx + PHP 应用,它们的关系如下图所示:
其中,wrk 和 curl 是 Nginx 的客户端,而 PHP 应用则是一个简单的 Hello World:
<?php echo "Hello World!" ?>
为了方便你运行,我已经把案例应用打包成了两个 Docker 镜像,并推送到 Docker Hub 中。你可以直接按照下面的步骤来运行它。
同时,为了分析方便,这两个容器都将运行在 host network 模式中。这样,我们就不用切换到容器的网络命名空间,而可以直接观察它们的套接字状态。
我们先在终端一中,执行下面的命令,启动 Nginx 应用,并监听在 80 端口。如果一切正常,你应该可以看到如下的输出:
docker run --name nginx --network host --privileged -itd feisky/nginx-tp 6477c607c13b37943234755a14987ffb3a31c33a7f04f75bb1c190e710bce19e $ docker run --name phpfpm --network host --privileged -itd feisky/php-fpm-tp 09e0255159f0c8a647e22cd68bd097bec7efc48b21e5d91618ff29b882fa7c1f
然后,执行 docker ps 命令,查询容器的状态,你会发现,容器已经处于运行状态(Up)了:
docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 09e0255159f0 feisky/php-fpm-tp "php-fpm -F --pid /o…" 28 seconds ago Up 27 seconds phpfpm 6477c607c13b feisky/nginx-tp "/init.sh" 29 seconds ago Up 28 seconds nginx
不过,从 docker ps 的输出,我们只能知道容器处于运行状态。至于 Nginx 能不能正常处理外部的请求,还需要我们进一步确认。
接着,切换到终端二中,执行下面的 curl 命令,进一步验证 Nginx 能否正常访问。如果你看到“Hello World!” 的输出,说明 Nginx+PHP 的应用已经正常启动了:
curl http://192.168.0.30 Hello World!
提示:如果你看到不一样的结果,可以再次执行 docker ps -a 确认容器的状态,并执行 docker logs < 容器名 > 来查看容器日志,从而找出原因
接下来,我们就来测试一下,案例中 Nginx 的吞吐量。
我们继续在终端二中,执行 wrk 命令,来测试 Nginx 的性能:
# 默认测试时间为 10s,请求超时 2s $ wrk --latency -c 1000 http://192.168.0.30 Running 10s test @ http://192.168.0.30 2 threads and 1000 connections Thread Stats Avg