针对容器的nginx优化

背景

容器技术越来越普遍，很多公司已经将容器技术作为基础架构的一部分，容器中可以运行任何软件，包括 Web Server、Application Server、数据库和存储系统等，其中 Nginx 作为 Web Server 使用也非常的普遍，接下来本文简要分析下 Nginx 在容器内使用遇到的一点小问题。

我们在物理机上配置 Nginx 时通常会将 Nginx 的 worker 进程数配置为 CPU 核心数并且会将每个 worker 绑定到特定 CPU 上，这可以有效提升进程的 Cache 命中率，从而减少内存访问损耗，不放过任何能够榨取系统性能的机会；对于需要手动配置 Nginx 进程个数的场景不在本文的探讨范畴内，例如：磁盘 IO 密集型业务可能会导致 Nginx 进程阻塞，我们通常会将 Nginx 的进程数设置为 CPU 核数的 2 倍，用于提高整体的并发。

在 Nginx 配置中指定 worker_processes 指令的参数为 auto 来自动检测系统的 CPU 核心数从而启动相应个数的 worker 进程，那么在 Linux 系统上 Nginx 是怎么获取 CPU 核心数的呢？答案是通过系统调用 sysconf(_SC_NPROCESSORS_ONLN) 获取到系统当前可用的 CPU 核心数。假如我们在一个 CPU 是 32 cores 的物理机上启动 Nginx，那么 sysconf(_SC_NPROCESSORS_ONLN) 返回值为 32。

存在问题

如果我们将 Nginx 放进 Docker 启动的容器内，sysconf(_SC_NPROCESSORS_ONLN) 的返回值是多少呢？

通过 docker run 启动一个带有 Nginx 的容器，暂时不对此容器的 CPU 资源做任何限制也就是可以使用物理机上的所有资源，我们来观察 Nginx 进程启动的进程数（确认 Nginx 配置中的 worker_processes 指令设置为 auto），答案其实大家都清楚的 Nginx 启动了 32 个 worker 进程。

接下来我们对容器的 CPU 资源做限制，通过 docker run 时指定 –cpuset-cpus=”0,1″ 参数绑定容器内的进程到 CPU-0 和 CPU-1 上，而后再来观察 Nginx 进程启动的进程数，同样还是 32 个 worker 进程；对容器设置 cpu-shares 和 cpu-quota 也会得到同样的结果。

那么问题来了：

1. 与我们预期的相符吗？

2. 指定了 –cpuset-cpus 能使用的核心数为 2 个，为什么获取到的 CPU 核心数还是 32 呢？

第 1 个问题：

很多人都是知道的，我们更期望的结果对于上边的设置只启动两个 worker 进程，进程得到的 CPU 时间片期望被 2 个进程分摊，现在需要被 32 个进程分摊；从 Nginx 角度来看想要取得更多的时间片就需要减少在这个 CPU 上运行的进程，这样整体性能才会提升。对于 Nginx 来说也就是期望根据可用的 CPU 核数启动相应的进程数，而不是根据物理机上可用的 CPU 核数来设置进程数。

第 2 个问题：

对于容器来说目前还只是一个轻量级的隔离环境，它并不是一个真正的操作系统，那么在容器中获取可用 CPU 核心数和 Memory 大小均是物理机配置。在没有容器的时候很多软件依赖于操作系统的资源进行初始化配置的，例如：JVM 根据 CPU 核数启动相应的 gc 线程，根据物理机的 memroy 设置堆大小。

压测比照

我们通过一个简单的压测比照一下在容器中 Nginx 启动不同 worker 进程对 QPS 和 Latency 影响有多大。

物理机：32cores

容器参数：

cpu-quota=400000（即容器内的进程最多可以使用 400% 的 CPU）

压测指令：

wrk -t 32 -c 500 -d 180 http://container_ip

提前准备：

容器内安装 Openresty、将 worker_processes 修改为 4 和 32，关闭 access 日志，响应数据为 541byte。

以下是 Nginx 的 QPS 和 Latency 压测结果，QPS 从 12 万 + 降到了 4 万 +，Latency 也从 6+ms 降到了 25+ms。