背景
容器技术越来越普遍，很多公司已经将容器技术作为基础架构的一部分，容器中可以运行任何软件，包括 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 也会得到同样的结果。
那么问题来了：
- 与我们预期的相符吗？
- 指定了 --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。
解决方法
从以上压测数据可以看出，Nginx 在设置 worker 进程数为 4 和 32 时 QPS 和 Latency 有很大的差距的，了解了以上问题我们该如何解决呢？方法 1：
先来说一下普遍使用的 Lxcfs，对于上边提到的场景是不适用的，Lxcfs 目前仅支持改变容器的 CPU 视图（/proc/cpuinfo 文件内容）并且只有 --cpuset-cpus 参数可以生效，对于系统调用 sysconf(_SC_NPROCESSORS_ONLN) 返回的同样还是物理机的 CPU 核数。
方法 2：
通过创建引导程序根据容器可以使用的物理资源自动计算出合理值并设置应用程序的启动参数，例如：通过 shell 脚本动态修改 Nginx 的 worker 进程数。
方法 3：
应用程序自行解析容器内的 cgroup 信息，并设置程序的启动参数。Docker 在 1.8 版本以后将容器分配的 cgroup 信息挂载进了容器内部，在容器内可以通过解析 cgroup 信息获取到当前容器可以使用的资源信息。例如：JDK 10 中引入了支持 Docker 容器的资源检测并配置 JVM 的运行时参数，它的原理就是解析容器内的 cgroup 信息配置 gc 线程数以及堆大小。
方法 4：
劫持系统调用 sysconf，在类 Unix 系统上可以通过 LD_PRELOAD 这种机制预先加载个人编写的的动态链接库，在动态链接库中劫持系统调用 sysconf 并根据 cgroup 信息动态计算出可用的 CPU 核心数。
小结
我们团队也参考了 JVM 的实现并根据 Nginx 的代码风格给 Nginx 打了一个 patch，使 Nginx 的 worker_processes auto 参数能够根据当前容器的可用资源自动计算出合理的 worker 进程数，同时也提交给了 Nginx 社区，但是很遗憾 Nginx 社区负责人 Maxim 并不愿意接受这种实现方式，他更希望的是容器能透明支持 sysconf(_SC_NPROCESSORS_ONLN) 系统调用的功能，而不是用这种解析 cgroup 文件的方式实现，于是我们就实现了一个可以劫持系统调用 sysconf 的动态链接库。可能有人会有疑问，为什么 JVM 能接受解析 cgroup 文件这种方式，而 Nginx 却不能接受这种方式呢？
根据我的理解目前这个小问题对 Nginx 不是最痛的，不支持也不妨碍使用，另一点是 Nginx 作者以及现在的主要维护者 Maxim 都有重度代码洁癖，从代码风格以及代码中几乎无注释可以感受的到，Nginx 推崇的是代码即文档，要求写代码的人像写文档一样使代码的可读性非常高，对于这种用几百行代码解决的问题他们更不能忍受。而 JVM 支持的这种方式很大原因是这个问题的确很痛，网上有很多人都有报 JVM 在容器内的配置不合理导致运行时出现各种问题，所以目前通用的解决方案也只能是解析 cgroup 文件来自动化支持。
