如何解决容器中 nginx worker process 自动设置的问题

最新推荐文章于 2025-10-26 05:25:34 发布
转载 最新推荐文章于 2025-10-26 05:25:34 发布 · 6.9k 阅读 · 7


Docker 技术鼻祖系列

原文链接：https://ieevee.com/tech/2020/05/11/nginx-process-auto.html

1.  问题描述

nginx 容器化时，有一个普遍会遇到的问题：如何自动设置 nginx worker process 的数量？

nginx 官方容器镜像的 nginx.conf 配置文件中，会有一条 worker process 配置：

它会配置 nginx 仅启动 1 个 worker。这在 nginx 容器为 1 核时，可以良好的工作。

当我们希望 nginx 给更高的配置，例如 4c 或者 16c，我们需要确保 nginx 也能启动响应个数的 worker process。有两个办法：

  1. 修改 nginx.conf，将 worker_processes 的个数调整为对应的 cpu 核数。

  2. 修改 nginx.conf，将 worker_processes 修改为 auto。

第一个方法可行，但是需要修改配置文件，nginx 需要 reload。实际部署时，必须将 nginx.conf 作为配置文件挂载，对一些不太熟悉 nginx 的用来说，心智负担会比较重。

第二个方法，在 Kubernetes 上会遇到一些问题。通过在容器中观察可以发现，nginx 启动的 worker process，并没有遵循我们给 Pod 设置的 limit，而是与 Pod 所在 node 的 cpu 核数保持一致。

这在宿主机的 cpu 核数比较多，而 Pod 的 cpu 配置较小时，会因为每个 worker 分配的时间片比较少，带来明显的响应慢的问题。

2. 问题原因

我们知道，在 Kubernetes 为容器配置 cpu 的 limits 为 2 时，容器其实并不是真正的 “分配了”2 个 cpu，而是通过 cgroup 进行了限制。

resources:
  limits:
    cpu: 500m
    memory: 256Mi
  requests:
    cpu: 500m
    memory: 256Mi

我们到这个 Pod 所在宿主机上去查看相关信息。

$ docker inspect 17f5f35c3500|grep -i cgroup
            "Cgroup": "",
            "CgroupParent": "/kubepods/burstable/podb008ccda-9396-11ea-bc20-ecf4bbd63ee8",
            "DeviceCgroupRules": null,
$ cd /sys/fs/cgroup/cpu/kubepods/burstable/podb008ccda-9396-11ea-bc20-ecf4bbd63ee8
$ cat cpu.cfs_quota_us
$ cat cpu.cfs_period_us

可以看到，实际是通过 cpu.cfs_quota_us/cpu.cfs_period_us 来限制该 Pod 能使用的 cpu 核数的。

但是 nginx 的 worker_processes，是通过 sysconf(_SC_NPROCESSORS_ONLN) 来查询宿主机上的 cpu 个数的（getconf _NPROCESSORS_ONLN），我们通过 strace 来观察下这个过程。

$ strace getconf _NPROCESSORS_ONLN
execve("/bin/getconf", ["getconf", "_NPROCESSORS_ONLN"], [/* 23 vars */]) = 0
brk(0)                                  = 0x606000
...
open("/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 3
read(3, "0-31\n", 8192)                 = 5
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a922a0000
write(1, "32\n", 332

可见，getconf _NPROCESSORS_ONLN实际是通过读取文件/sys/devices/system/cpu/online来获取 cpu 个数的。

默认 Kubernetes 上，/sys/devices/system/cpu/online文件实际就是宿主机的，因此，nginx 启动的 worker process 个数，与宿主机 cpu 个数一致，也就不奇怪了。

3. 解决方案

解决方案实际也不难想到，修改容器中的/sys/devices/system/cpu/online就行了。

社区的 lxcfs 已经解决了这个问题。

lxcfs

LXCFS 是一个小型的 FUSE 文件系统，其目的是让 Linux 容器感觉更像一个虚拟机。LXCFS 会关注的 procfs 中的关键文件：

/proc/cpuinfo
/proc/diskstats
/proc/meminfo
/proc/stat
/proc/swaps
/proc/uptime
/sys/devices/system/cpu/online

可以看到，我们需要的/sys/devices/system/cpu/online文件，也在 lxcfs 关注列表中。

lxcfs 的使用方法也比较简单，只要将宿主机的/var/lib/lxc/lxcfs/proc/online挂载到容器的/sys/devices/system/cpu/online就可以了。

containers:
- args:
  - infinity
  command:
  - sleep
  volumeMounts:
  - mountPath: /sys/devices/system/cpu/online
    name: lxcfs-2
    readOnly: true
volumes:
- hostPath:
    path: /var/lib/lxc/lxcfs/proc/online
    type: ""
  name: lxcfs-2

当我们在容器中读取/sys/devices/system/cpu/online文件时，由于 kubelet 将该文件绑定了/var/lib/lxc/lxcfs/proc/online，该 read 请求会交给 lxcfs daemon 来处理。

lxcfs 实际处理的函数如下。

int max_cpu_count(const char *cg)
{
 __do_free char *cpuset = NULL;
 int rv, nprocs;
 int64_t cfs_quota, cfs_period;
 int nr_cpus_in_cpuset = 0;

 read_cpu_cfs_param(cg, "quota", &cfs_quota);
 read_cpu_cfs_param(cg, "period", &cfs_period);

 cpuset = get_cpuset(cg);
 if (cpuset)
  nr_cpus_in_cpuset = cpu_number_in_cpuset(cpuset);

 if (cfs_quota <= 0 || cfs_period <= 0){
  if (nr_cpus_in_cpuset > 0)
   return nr_cpus_in_cpuset;

  return 0;
 }

 rv = cfs_quota / cfs_period;

 /* In case quota/period does not yield a whole number, add one CPU for
  * the remainder.
  */
 if ((cfs_quota % cfs_period) > 0)
  rv += 1;

 nprocs = get_nprocs();
 if (rv > nprocs)
  rv = nprocs;

 /* use min value in cpu quota and cpuset */
 if (nr_cpus_in_cpuset > 0 && nr_cpus_in_cpuset < rv)
  rv = nr_cpus_in_cpuset;

 return rv;
}

根据前面的信息，可以看到最终返回的值为 200000/100000 = 2。

4. 结论

因此，当有 lxcfs 的加持时，nginx 可以放心的将 worker_processes 配置为auto，不需要担心启动了过多的 worker processes。


你可能还喜欢

点击下方图片即可阅读

最华丽的 Kubernetes 桌面客户端：Lens

云原生是一种信仰 ????

扫码关注公众号

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！

点击 "阅读原文" 获取更好的阅读体验！

❤️给个「在看」，是对我最大的支持❤️
实战教程：如何在CentOS7中使用Docker部署Keepalived和Nginx构建高可用Web集群
jks212454的博客
07-09 1104
实战教程：如何在CentOS7中使用Docker部署Keepalived和Nginx构建高可用Web集群
【Nginx】docker配置Nginx+tomcat负载均衡（记录了正确的nginx和tomcat容器以及配置经典错误！！）
AloneYue优快云
10-03 5504
文章目录1.nginx.conf的配置2.9080和9081 tomcat 1.nginx.conf的配置 upstream myserver{ #ip_hash; server localhost:9080 weight=1; server loaclhost:9081 weight=1; } server { listen 9001; server_name localhost; #server_name www.my
nginx worker_processes配置详解：设置 Nginx 启动的工作进程数
学亮编程手记
11-12 3279
是 Nginx 配置文件中的一个重要指令，用于设置 Nginx 启动的工作进程数。合理配置可以显著提升 Nginx 的性能和稳定性。
Nginx基本操作
Miraitowa_xu的博客
02-25 1460
ngnix会根据用户请求的URI来检查定义的所有location，按一定的优化级找出一个最佳匹配，而后应用其配置在没有使用正则表达式的时候，nginx会先在server中的多个location选取匹配度最高的一个uri，uri是用户请求的字符串，即域名后面的web文件路径，然后使用该location模块中的正则url和字符串，如果匹配成功就结束搜索，并使用此location处理此请求。#用于标准url前，表示包含正则表达式,并且匹配以指定的正则表达式开头,对URI的最左边部分做匹配检查，不区分字符大小写。
Nginx并发连接调优：Linux-Tutorial中的worker_processes配置
最新发布
gitblog_00852的博客
10-26 715
你是否曾遇到过网站访问量突增时，服务器响应变慢甚至卡顿的情况？这往往与Nginx的并发处理能力不足有关。本文将详细介绍如何通过优化`worker_processes`配置提升Nginx并发连接处理能力，读完你将掌握：不同服务器环境下的`worker_processes`设置方法、并发连接数的计算方式、系统参数调优技巧以及实际配置案例分析。 ## Nginx工作进程与并发连接原理 Nginx采用...
Nginx配置文件详解
LCK 博客
06-03 2518
一、Nginx的配置文件的组成 主配置⽂件：/编译安装目录/conf/nginx.conf ⼦配置⽂件：/编译安装目录/conf/conf.d/*.conf 配置文件中的指令：include conf.d/*.conf fastcgi，uwsgi，scgi等协议相关的配置⽂件 mime.types：⽀持的mime类型的配置文件 二、Nginx的配置文件格式 directive value [value2 ...]; 注意： (1) 指令必须以分号结尾 (2) ⽀持使⽤配置变量 ...
Nginx性能优化配置
dehuisun的专栏
07-28 4358
worker进程数(worker_processes )默认为 1 ，单进程最大连接数(worker_connections)为1024每个 worker 进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能如果这些模块确认不会出现阻塞式的调用，那么有多少CPU内核就应该配置多少个进程反之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。
NGINX 性能调优/优化 （整合篇）
IChen.的博客
04-16 4703
第一篇 目录： 1、Nginx运行工作进程数量 Nginx运行工作进程个数一般设置CPU的核心或者核心数x2。如果不了解cpu的核数，可以top命令之后按1看出来，也可以查看/proc/cpuinfo文件 grep ^processor /proc/cpuinfo | wc -l [root@lx~]# vi/usr/local/nginx1.10/conf/nginx.conf worker_p...
6. Nginx性能参数调优
@子敬的博客
05-21 454
1. worker_processes 语法:worker_processes number | auto; * number：Nginx进程最多可以产生的工作进程数量 * auto： Nginx进程将自动检测 Nginx服务器实现并发处理服务的关键。 每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用，那么，有多少CPU内核就应...
Nginx配置之worker_processes
fendoudebb的博客
08-01 7906
1.9.10版本后可以配置 worker_processes auto; worker_cpu_affinity auto; 解释：0001表示启用第一个CPU内核，0010表示启用第二个CPU内核，依此类推 worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; 参考：http://www.nginx.org/en/docs/ngx_core_module.html#worker_cpu_affinity ...
nginx 并发数问题思考：worker_connections,worker_processes与 max clients
weixin_34415923的博客
05-31 499
我相信，很多人都跟我一样，看书都不会太细致也不太认真思考，感觉书中讲的东西都应该是对的，最近读书时我发现以前认为理所当然的东西事实上压根都没有弄明白，最终的结果是，书是别人的，书中的知识也是别人的。 无论是看过的nginx有关书还是网上看到的有关nginx 配置说明的文章（http://wiki.nginx.org/EventsModule#worker_conn...
Nginx专题（七、启动流程）
酱油师兄的博客
10-18 633
终于艰难的把使用nginx使用高完了，接下来看看nginx源码分析，分析一下前辈任务写的优秀源码。
[root@ec-tna-27-3 ~]# ps -ef | grep nginx | grep -v grep root 17273 17253 0 2024 pts/0 00:00:00 nginx: master process nginx -g daemon off; www 64066 17273 0 Jun04 pts/0 00:00:09 nginx: worker process
06-06
根据引用内容，我们可以提取以下相关信息：引用[1]：展示了使用`ps-axu|grepnginx`（注意，用户命令是`ps-ef`，但原理类似）查看Nginx进程的例子，输出中包括masterprocess和多个workerprocess。引用[2]：涉及nginx...
卸载nginx [root@localhost ~]# /usr/local/nginx/sbin/nginx -s stop nginx: [emerg] the INET6 sockets are not supported on this platform in "[::]:80" of the "listen" directive in /usr/local/nginx/conf/nginx.conf:38 [root@localhost ~]# ps -ef |grep nginx root 11707 1 0 16:02 ? 00:00:00 nginx: master process nginx nginx 12276 11707 0 16:10 ? 00:00:00 nginx: worker process nginx 12277 11707 0 16:10 ? 00:00:00 nginx: worker process root 12906 10790 0 16:20 pts/1 00:00:00 grep --color=auto nginx [root@localhost ~]# ./nginx -s stop -bash: ./nginx: 没有那个文件或目录
06-18
我们正在解决Nginx卸载过程中遇到的问题，特别是关于停止Nginx进程时出现的错误。用户提到了两个问题：stop命令失败和INET6sockets不支持。根据引用[4]，我们知道在停止服务时，如果进程能够收到SIGTERM信号，就可以...
【中间件】Nginx中配置`worker_processes`
weixin_45226922的博客
03-27 1317
在Nginx中配置。
nginx worker_processes
Claroja
01-18 600
pdf
ngnix优化，高并发配置参数worker_processes
热门推荐
sh2018的博客
11-13 1万+
/etc/nginx/nginx.conf worker_processes默认为1，官方说1一般情况足够了 也可以设置为cpu核心说，2或者4或者8，再高没大意义 或者省事些，直接设置为auto，根据需求自动调整   参考 https://www.cnblogs.com/felixzh/p/6283816.html https://www.cnblogs.com/aaron-agu...
Nginx进程模型
weixin_45881674的博客
07-20 878
Nginx进程模型
docker里安装nginx容器、同时配置多个nginx容器
zjh_746140129的博客
04-13 1万+
本篇文章主要介绍在Linux（Centons7）下安装docker的中安装nginx容器，以下分为大概步骤和详细步骤，也会把一些遇到的坑和解决方案经验分享给大家，nginx容器安装其实就是下载启动即可，配置多个nginx需要额外修改即可。 Docker的三大核心概念：镜像、容器、仓库 镜像：类似虚拟机的镜像、用俗话说就是安装文件。 容器：类似一个轻量级的沙箱，容器是从镜像创建应用运行实例， ...
Docker镜像包启动卡在start worker process
08-28
<think>我们正在解决Docker镜像启动时卡在"start worker process"的问题。根据用户提供的引用和问题描述，我们需要分析可能导致此问题的原因并提供解决方案。 可能的原因： 1. 应用程序启动时需要较长时间初始化（例如数据库连接、资源加载等） 2. 应用程序配置问题（例如等待某个服务或端口） 3. 资源限制（内存、CPU不足导致进程卡住） 4. 死锁或程序逻辑错误 5. 日志输出缓冲区问题（导致日志没有及时输出） 解决步骤： 1. 检查容器日志： 使用`docker logs <container_id>`查看容器日志，注意加上`-f`参数可以实时查看，但如果是卡住可能不会有新日志。重点查看卡住之前的最后几条日志。 2. 进入容器内部检查： 如果容器没有完全退出，可以尝试使用`docker exec -it <container_id> /bin/bash`进入容器，检查进程状态和资源使用情况。 3. 调整Docker运行参数： 尝试在运行容器时增加`--privileged`（有时权限问题会导致进程卡住）或调整资源限制（如内存、CPU）。 4. 检查应用程序配置： 查看应用程序的配置文件，确认是否有等待外部服务（如数据库）的配置，而外部服务不可用导致一直等待。 5. 使用调试模式启动应用程序： 如果可能，修改Dockerfile，使应用程序以调试模式启动，以便输出更多信息。 6. 检查启动脚本： 检查启动脚本（如entrypoint.sh）中是否有错误，比如某个命令没有退出（例如tail -f命令）。 7. 分析堆栈跟踪： 如果进程还在运行，可以尝试获取进程的堆栈信息（例如使用`jstack`对于Java应用，或`gdb`等）。 8. 检查网络连接： 使用`docker run`时加入`--network=host`使用主机网络，排除网络问题。 9. 尝试简化镜像： 如果镜像基于复杂的基础镜像，尝试使用更简单的基础镜像（如alpine）来排除基础镜像问题。 10. 检查文件系统挂载： 检查是否有挂载的卷（-v参数）导致的问题，尝试不挂载任何卷运行。 根据引用[3]中提到的，我们可以使用`--entrypoint`参数覆盖默认的入口点，进入容器内部进行排查。 例如： docker run -it --entrypoint /bin/bash <image_name> 然后手动执行启动命令，观察启动过程。 另外，引用[1]和[2]提供了镜像构建和容器操作的相关命令，我们可以利用这些命令来构建和运行容器。 具体操作步骤建议： 步骤1：查看日志 docker logs <container_id> --tail 100 -f 步骤2：进入容器调试（如果容器还在运行） docker exec -it <container_id> /bin/bash 步骤3：如果容器没有运行，则使用覆盖入口点的方式启动一个新容器： docker run -it --entrypoint /bin/sh <image_name> 然后手动执行应用程序的启动命令，观察输出。 步骤4：检查资源使用情况 在宿主机上使用`docker stats`查看容器的资源使用情况。 步骤5：如果应用程序是Web服务，检查端口是否正常监听 在容器内执行：netstat -tuln 步骤6：检查应用程序依赖的服务 例如，如果应用程序需要连接数据库，确保数据库可访问。 步骤7：如果以上步骤无法解决，考虑在Dockerfile中添加调试工具（如vim, net-tools, procps等），重新构建镜像并运行。 示例Dockerfile修改（在原有基础上增加工具）： FROM tinyhttpd:v0.1-7 RUN apk add --no-cache curl vim net-tools procps # 假设基础镜像基于alpine # 或者如果是基于debian/ubuntu的镜像：RUN apt-get update && apt-get install -y curl vim net-tools procps 然后重新构建镜像并运行。 步骤8：如果问题仍然存在，可能需要检查应用程序本身的代码，特别是启动过程中“start worker process”的部分。 由于用户的问题描述中提到了“start worker process”，这通常与Web服务器（如Nginx、Gunicorn等）启动工作进程有关。因此，我们可以重点检查工作进程的配置和日志。 例如，对于Gunicorn，可以尝试增加`--log-level=debug`来获取更详细的日志。 总结：需要根据具体的应用程序和环境进行排查，以上步骤为通用排查方法。</think>### Docker镜像启动卡在"start worker process"的解决方法 当Docker容器启动卡在"start worker process"时，通常表示工作进程启动过程中遇到阻塞。以下是系统化的排查和解决方法： #### 1. **检查容器日志（关键步骤）** ```bash docker logs --tail 50 <container_id> # 查看最后50行日志 docker logs -f <container_id> # 实时跟踪日志 ``` - 重点观察卡住前的最后一条有效日志 - 常见阻塞原因： - 数据库连接失败（如等待MySQL） - 配置文件错误（如无效端口绑定） - 依赖服务未就绪（如Redis未启动） #### 2. **进入容器调试** ```bash docker run -it --entrypoint=/bin/sh <image_name> # 覆盖入口点 ``` 在容器内手动执行启动命令： ```bash # 示例（根据实际应用调整）： /usr/sbin/nginx -g "daemon off;" # 前台运行Nginx python app.py # 直接运行Python应用 ``` - 观察终端输出的具体错误 - 检查`/proc/<pid>/status`确认进程状态 #### 3. **资源限制排查** ```bash docker run --memory=512m --cpus=1 <image> # 测试资源限制 ``` - 使用`docker stats`监控资源使用： ```bash CONTAINER ID CPU % MEM USAGE / LIMIT cccb2108056e 0.01% 150MiB / 512MiB # 示例输出[^2] ``` - 常见问题： - 内存不足导致OOM Killer终止进程 - CPU配额不足使进程饥饿 #### 4. **网络问题诊断** ```bash docker run --network=host <image> # 使用主机网络测试 ``` 在容器内检查： ```bash nc -zv 数据库IP 3306 # 测试数据库连通性 curl -I http://localhost # 测试本地服务 ``` #### 5. **文件权限修复** ```bash docker run -v /host/path:/container/path:Z <image> # SELinux权限 docker run --user $(id -u):$(id -g) <image> # 指定用户[^3] ``` - 检查关键目录权限： ```bash ls -ld /var/run # 确保PID文件目录可写 ``` #### 6. **应用层优化** - **启动脚本**：添加超时检测 ```bash #!/bin/sh timeout 30s /app/start.sh || echo "启动超时" ``` - **日志级别**：提升为DEBUG（如Nginx的`error_log debug;`） - **健康检查**：在Dockerfile中添加： ```dockerfile HEALTHCHECK --interval=5s --timeout=3s \ CMD curl -f http://localhost/ || exit 1 ``` #### 7. **高级调试手段** - **堆栈跟踪**： ```bash docker exec <container> kill -SIGUSR1 <worker_pid> # 触发日志转储 ``` - **核心转储**： ```bash docker run --ulimit core=-1 <image> # 启用核心转储 ``` #### 典型解决方案流程 ```mermaid graph TD A[启动卡住] --> B[检查日志] B --> C{发现错误？} C -->|是| D[根据错误修复] C -->|否| E[进入容器调试] E --> F{阻塞原因？} F -->|资源不足| G[调整内存/CPU] F -->|网络问题| H[检查端口/防火墙] F -->|权限问题| I[修复文件权限] F -->|应用BUG| J[代码修复] ``` ### 常见根本原因统计 | 原因类型 | 占比 | 典型表现 | |----------------|------|------------------------| | 外部依赖未就绪 | 40% | 数据库连接超时 | | 配置错误 | 25% | 无效端口绑定 | | 资源不足 | 20% | OOM Killer终止进程 | | 权限问题 | 10% | Permission denied | | 应用BUG | 5% | 死锁/无限循环 | > **提示**：当使用`docker stop`强制停止容器时，可能残留僵尸进程，建议用`docker rm -f`彻底清理后再测试[^2]。
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值