我们刚刚从 3.0.6 更新到 3.1.2，并且在 3 个主要位置看到了许多 503 错误：
- 许多头像加载失败
- 图片上传仅有时有效
- 还看到了许多关于
topics/timings 的错误
我查看了服务器日志，大多数 503 错误甚至没有显示在 production.log 中，但 nginx 中到处都是。考虑到可能是 nginx 速率限制，我尝试不使用 templates/web.ratelimited.template.yml，但似乎没有帮助。我仍然看到大量请求被 503 回复，主要是 user_avatars/show，据我所知，production.log 似乎根本没有看到它们。
没有注意到 sidekiq 中有任何问题。但是，/logs 中确实有错误，
'hijack user_avatars show ' 在 db default 上运行了 90 秒后仍然运行，此进程可能需要重启！
但这些是几个小时前发生的，在那之后我重建了实例几次，它们没有再次出现。
此实例使用 SSO，因此头像（URL）来自那里。我们使用 S3 进行图片存储。
我对是什么导致了这个问题感到有些困惑，也想不出其他办法了。
有什么线索可以查看哪里/什么吗？
服务器有 16GB 内存，在更新前已经运行了好几个月，一直都没问题。
这是一台 AWS 实例，在更新前不久（Discourse 数据在 EBS 卷上）为了更改一些不相关的参数而启动的。
更新后网络流量（入站和出站）显著增加：头像在最初的 503 错误后几秒钟似乎可以工作了，所以我猜测在首次请求时有一些进程在运行。
然而，我不明白为什么图片上传会随机失败，topics/timings 端点也是如此。
不确定这是否与此有关：
会不会是这个头像后台更新进程达到了 AWS 的 3500 PUT/s 速率限制，导致常规上传失败，而头像正在更新？/cc @sam
1 个赞
是的，部分是。
更新于 21 日上午。入站网络流量似乎正在恢复正常。出站流量仍高于正常水平，但我认为这是因为头像正在被缓存。到 user_avatars/show 的 503 错误数量已大大减少。我猜随着更多头像被处理，这些错误会逐渐得到解决。
然而，我们仍然在日志中看到大量 503 错误，主要针对另外两个端点：
POST /topics/timings
此端点仍有大量 503 错误，并且一些用户报告已访问的主题未被标记为已读。我没有找到任何关于此的信息，因为请求似乎根本没有在 production.log 中记录。/logs 中也没有显示任何相关内容。
一个人应该在哪里调试这些 503 错误？是否有我不知道的其他日志，或者是否有办法使日志更详细（在生产系统上）？
POST /uploads.json?client_id=...
我在 production.log 中找到的关于这些 503 错误的唯一信息如下：
从 production.log 中提取
Started POST “/uploads.json?client_id=X” for x.x.x.x at 2023-10-24 10:24:55 +0000
Processing by UploadsController#create as JSON
Parameters: {“upload_type”=>“composer”, “relativePath”=>“null”, “name”=>“Screenshot 2023-10-24 at 11.22.32.png”, “type”=>“image/png”, “sha1_checksum”=>“d1f11731320437724003c3840c5dcc5f934ba25a”, “file”=>#<ActionDispatch::Http::UploadedFile:0x00007f3c5e3c9898 @tempfile=#Tempfile:/tmp/RackMultipart20231024-1991-b30vit.png, @content_type=“image/png”, @original_filename=“Screenshot 2023-10-24 at 11.22.32.png”, @headers=“Content-Disposition: form-data; name="file"; filename="Screenshot 2023-10-24 at 11.22.32.png"\r\nContent-Type: image/png\r\n”>, “client_id”=>“X”}
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 503 Service Unavailable in 10ms (Views: 0.4ms | ActiveRecord: 0.0ms | Allocations: 5007)
我们的用户报告说他们重试了几次直到成功……如果我尝试上传（另一个）文件，而有一个文件仍在上传，我就可以比较一致地重现这个错误。逐个上传似乎不太容易出错，原因不明。
# free -h
total used free shared buff/cache available
Mem: 15Gi 3.8Gi 621Mi 1.1Gi 10Gi 10Gi
# lscpu --parse=core | egrep -v # | sort -u | wc -l
2
UNICORN_WORKERS: 4
db_shared_buffers: "1024MB"
