'768 worker_connections' 不足错误

支持 安装
1

嘿！

由于今天进行了重建，我们正经历大量的服务器错误。这似乎是一个 nginx 连接问题；在 nginx/error.log 中，我偶尔会看到如下爆发的 768 worker_connections are not enough 消息：

2021/06/02 10:42:21 [alert] 1143#1143: *28468 1768 worker_connections are not enough while connecting to upstream, client: (IP removed), server: _, request: "POST /message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t HTTP/1.1", upstream: "http://127.0.0.1:3000/message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t", host: "blenderartists.org", referrer: "https://blenderartists.org/t/convert-multiple-objects-to-single-mesh-with-vertex-grouping/489173/2"

有什么办法可以解决这个问题吗？我们的 CPU 和内存资源非常充足——能否增加“工作进程连接数”（worker connections）？

2 个赞
2

更新：我暂时增加了工作进程连接数，但依然会出现这些错误（频率降低，且在高工作进程数量下出现）。我真的很想知道最近是否有某些变更可能导致此问题，或者我该如何更好地追踪定位。

## 构建后需要运行的任何自定义命令
run:
  - exec: echo "开始执行自定义命令"

  - replace:
      filename: "/etc/nginx/letsencrypt.conf"
      from: "worker_connections 768" 
      to: "worker_connections 1768"
2 个赞
3

有趣的是，这在重建后发生了。您最近是否执行过任何批量操作？建议您检查 Sidekiq 日志，看看那里是否也有大量任务。

1 个赞
4

我最近确实执行了一些批量操作，因为我们切换到了缩略图预览 TC，但我的 Sidekiq 队列中没有任何任务，我可以肯定地排除这一点。

1 个赞
5

我们两天前升级了 nginx 版本，所以请密切关注。您的网站是否有超过 500 个并发访问者？

另外，您的整个网站都通过 Cloudflare 托管，因此情况可能会因此有所不同。

1 个赞
6

我不确定——也许有？有什么方法可以检查吗？

没错。但我已禁用所有加速功能，基本上只用它来缓存图片和头像。直到今天之前，这从未成为问题。

7

哈哈，通常人们会使用 Google Analytics 或类似工具来获取这类信息。Discourse 仪表盘也提供了每日页面浏览量（pageviews）和用户访问数，可以用来进行类似的估算。

事实并非如此，您的整个网站都是通过 Cloudflare 提供的：

curl -I https://blenderartists.org/                                                                                                                                         \nHTTP/2 200 \ncf-cache-status: DYNAMIC\ncf-request-id: 0a6ef945b3000002fe272b2000000001\nserver: cloudflare\ncf-ray: 6591c4b5ec5902fe-MIA\nalt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400, h3=":443"; ma=86400

不过，这可能与问题完全无关，因为您的 nginx 报错的是上游（upstream）连接问题，而非下游连接。这意味着 nginx 与 unicorn 之间的连接资源已耗尽。

由于我们借助 message_bus（实时更新服务）为每位访客保持一个开放连接，如果您的网站有一定人气，这种情况是可以预期的。

调大 worker_processes 和 worker_connections 是安全的，而且在您的情况下听起来很合理。我们默认将 worker_processes 设置为您的 CPU 核心数。请问您有多少个 CPU 核心？

2 个赞
8

确实如此 :slight_smile: 我们很久以前就停用那个了……我们每天的页面浏览量约为 25 万（包含机器人），所以 500 看起来并不算异常。用户访问量是不是只统计登录后的访问？

没错——我们确实需要通过 Cloudflare 转发请求，但我们不会让它们触碰我们的 JavaScript 等文件。

我们有 12 个核心，64GB 内存。典型负载约为 2，我们使用了 50% 的内存。

1 个赞
9

天哪，这也太奇怪了！

连接数的计算公式是 worker_processes * worker_connections，即 12 * 768，结果应该是（敲键盘声）9216。但你的日志显示是 1768……

在你的 app.yml 上尝试以下操作：

## 构建后运行的任何自定义命令
run:
  - exec: echo "开始执行自定义命令"

  - replace:
      filename: "/etc/nginx/nginx.conf"
      from: "worker_connections 768" 
      to: "worker_connections 2000"
  - replace:
      filename: "/etc/nginx/nginx.conf"
      from: "worker_processes auto" 
      to: "worker_processes 10"

请注意，你第 2 个帖子中的操作块针对的是错误的文件！

4 个赞
10

:facepalm: 我贴错了代码——我先试了 letsencrypt 模板，但后来把 nginx.conf 改成了 1768 个工作连接。

我会试试你的参数，稍后回来反馈结果。

1 个赞
11

恐怕问题依然存在：

2021/06/02 17:40:03 [alert] 2102#2102: *262491 在连接到上游服务器时，2000 个工作连接数不足，客户端：<ip removed>，服务器：_，请求："POST /message-bus/0e453fae0c604c29a876e6ede05b7341/poll?dlp=t HTTP/1.1"，上游："http://127.0.0.1:3000/message-bus/0e453fae0c604c29a876e6ede05b7341/poll?dlp=t"，主机："blenderartists.org"，引用页："https://blenderartists.org/t/weight-paint-not-painting/551282"
12

我已将 worker_connections 提升至 4000，目前情况良好：crossed_fingers:

7 个赞
13

现在我们更容易覆盖了：

3 个赞
14

太棒了！那么我们会在 app.yml/web_only.yml 中做类似这样的事情吗？

params:
  nginx_worker_connections: 4000
2 个赞
15

确实如此。我们在同一个补丁中还将默认值提高到了 4k，因此管理员可能需要仔细评估他们是否仍需要提高该值。

2 个赞
16

在一个网站上，我还将工作进程的 CPU 数量增加了一倍。我需要也删除那个吗？

1 个赞
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.