helmi
2022 年1 月 26 日 15:23
1
我想借鉴您的经验，了解如何继续扩展我们的硬件。
这是我们的基石数据：
目前有 220 万个帖子，每月增长约 8 万个
我们目前运行在 Hetzner 虚拟机上，拥有 8 个独占核心和 32G 内存。我们从 12 月开始遇到限制，首先是 Nginx 工作进程连接数，从默认的 768 增加到 1536。昨天我们再次达到了这个限制，现在将其增加到 3072。在这些更改之后，一切运行顺利，但我们已接近 100% 的服务器利用率限制。
db_work_mem 设置为 80MB，db_shared_buffers 设置为 8192MB。我们并没有完全使用可用的内存，但不确定是否有空间使用更多内存并从中受益。有什么想法？
#~\u003e free -m
total used free shared buff/cache available
Mem: 31360 6105 1241 8423 24013 16412
Hetzner 下一个简单的扩展选项是 16 核和 64GB 内存，这在成本方面对我们来说是可以接受的，但我不知道垂直扩展是否仍然有意义。我一直在想，将应用程序和数据库分离到不同的服务器是否更有意义，或者这是否会带来更多困难。
谁做过这样的事情？你们有什么经验？
Falco
2022 年1 月 26 日 18:11
2
您为什么希望扩展？您的 API 响应时间指标是否在下降？
helmi:
我们即将达到 100% 的服务器利用率限制。
您在这里指的是什么资源？CPU？磁盘空间？内存？
2 个赞
RGJ
2022 年1 月 26 日 18:35
4
您有多少页面浏览量？
忽略互联网上找到的所有建议，将其设置为您内存的 40-50%。
您能分享一些 sar 输出吗？
2 个赞
helmi
2022 年1 月 26 日 20:17
5
Falco:
您为什么想扩展？
因为我正在提前规划。我们现在可能不需要扩展，但考虑到我们看到的增长以及过去对资源日益增长的需求，我只是在提前规划，考虑下一步可能的措施。
Falco:
您在这里指的是什么资源？CPU？磁盘空间？内存？
主要是 CPU - 在今天的更新之后，我们在高峰时段的负载从大约 8-9 降至现在的约 6。
RGJ:
您有多少页面浏览量？
每月 1200 万，一年前为每月 650 万。
稍后我会提供 sar 的输出，我之前没有运行它。
helmi
2022 年1 月 26 日 20:33
7
从 CPU 时间来看，我认为主要是 unicorn 工作进程：
1 个赞
helmi
2022 年1 月 27 日 07:52
9
我已经在考虑那个选项了。我们之前使用了非专用 CPU，而“升级”到专用 CPU 并没有给我们带来多大的进步。
1 个赞
RGJ
2022 年1 月 27 日 10:30
10
我不确定 CPU 是否是您的瓶颈。您能否分享一些 sar 输出？
helmi
2022 年1 月 27 日 12:09
11
是的，但我还没有真正达到高峰时段。明天就会有了。
自从昨天提高工作连接数以来，CPU 使用率肯定降低了——但不知道降低了多少。
12:00:01 AM CPU %user %nice %system %iowait %steal %idle
08:45:01 AM all 40.22 2.21 7.44 0.27 0.00 49.86
08:55:01 AM all 42.84 2.89 8.02 0.16 0.00 46.09
09:05:01 AM all 38.81 0.86 7.68 0.12 0.00 52.53
09:15:01 AM all 38.80 0.70 7.66 0.10 0.00 52.73
09:25:01 AM all 38.71 2.14 7.88 0.12 0.00 51.16
09:35:01 AM all 38.74 0.84 7.86 0.09 0.00 52.47
09:45:01 AM all 40.31 1.07 7.95 0.10 0.00 50.57
09:55:01 AM all 40.03 1.37 7.90 0.08 0.00 50.62
10:05:01 AM all 39.00 1.29 7.90 0.09 0.00 51.72
10:15:01 AM all 40.26 2.68 8.07 0.09 0.00 48.91
10:25:01 AM all 41.59 0.93 8.31 0.08 0.00 49.09
10:35:01 AM all 40.39 1.55 8.25 0.07 0.00 49.73
10:45:01 AM all 45.44 2.37 9.08 0.08 0.00 43.03
10:55:01 AM all 50.56 2.20 9.23 0.06 0.00 37.95
11:05:01 AM all 41.82 1.54 8.55 0.08 0.00 48.02
11:15:01 AM all 38.74 1.54 8.11 0.10 0.00 51.50
11:25:01 AM all 45.41 1.59 9.27 0.19 0.00 43.55
11:35:01 AM all 38.45 1.78 8.20 0.11 0.00 51.45
11:45:01 AM all 41.03 1.60 8.48 0.14 0.00 48.75
11:55:01 AM all 40.65 1.17 8.36 0.15 0.00 49.67
12:05:01 PM all 40.03 1.29 8.40 0.13 0.00 50.15
12:15:01 PM all 40.47 1.10 8.19 0.11 0.00 50.13
1 个赞
RGJ
2022 年1 月 28 日 22:34
13
我怀疑 Postgres 没有获得足够的内存，这会导致 %iowait 很高。
pfaffman
2022 年1 月 29 日 04:07
14
我正在帮助别人解决性能问题。我们增加了 PostgreSQL 缓冲区大小。我认为这有点帮助，但 mini profiler 仍然显示超过 300 毫秒。CPU 使用率为 16 个 CPU 大约 30%。
1 个赞
helmi
2022 年1 月 29 日 07:22
15
看起来这种情况不会改变。我已经观察了两个晚上，CPU 使用率都没有升高。您关于 Postgres 的假设可能是正确的。
关于 mini profiler：我们想达到的目标是多少？我们目前大约在 300 毫秒。之前在 500 毫秒左右。
3 个赞
我认为，如果我们能在所有情况下低于 50 毫秒 ，无论高峰流量时段如何，我都称之为快速的服务器响应时间。网站的其余部分也会更快，因为一切都取决于初始服务器响应时间。
如果它能对所有地理位置的用户都保持在 50 毫秒以下并且保持一致，那就非常理想了。目前它一直在跳动，而且大部分时间都偏高，这似乎是导致缓慢的主要问题。
helmi
2022 年1 月 30 日 20:01
17
在过去几天里，一切都进展顺利，除了今天下午大约半小时。我当时不在服务器上，但我们在 nginx 日志中看到了来自后端的超时报告。sar 显示系统利用率略有升高，但没有普遍的高 CPU 负载。不确定那是什么，但它似乎阻碍了 unicorn/redis/postgres 的顺利运行。
03:55:01 PM all 34.99 1.87 6.67 0.12 0.00 56.35
04:05:01 PM all 33.99 0.35 6.52 0.31 0.00 58.82
04:15:01 PM all 35.24 1.17 7.14 0.13 0.00 56.31
04:25:02 PM all 36.45 0.63 7.15 0.13 0.00 55.65
> 04:35:01 PM all 39.09 0.71 16.78 0.11 0.00 43.32
> 04:45:01 PM all 35.53 0.95 20.16 0.08 0.00 43.27
> 04:55:01 PM all 41.64 4.29 15.44 0.24 0.00 38.39
05:05:01 PM all 36.75 2.47 7.78 0.13 0.00 52.87
05:15:01 PM all 35.96 1.29 7.81 0.10 0.00 54.85
05:25:01 PM all 38.69 1.35 8.00 0.09 0.00 51.87
05:35:01 PM all 37.01 4.53 7.92 0.07 0.00 50.46
这是标记了 > 的行。
当时看不到高流量，所以我不太清楚是什么原因，但它确实只在那半小时内发生。
总的来说，从 CPU 时间来看，Redis 占了主导地位，并且通常会占用大部分 CPU。不确定是否有什么可以做的。它通常在 20-25% 左右，偶尔会达到 35%。
1721566 uuidd 20 0 2035M 1458M 1952 S 16.1 4.6 16h22:37 /usr/bin/redis-server *:6379
1721578 www-data 20 0 108M 69100 12516 S 6.7 0.2 6h32:27 nginx: worker process
2853756 1000 20 0 1355M 444M 19356 R 63.7 1.4 2h38:10 unicorn worker[0] -E production -c config/unicorn.conf.rb
2854380 1000 20 0 1267M 409M 18768 S 41.6 1.3 2h19:45 unicorn worker[4] -E production -c config/unicorn.conf.rb
1721598 1000 20 0 592M 285M 5192 S 1.3 0.9 2h08:53 unicorn master -E production -c config/unicorn.conf.rb
575 root 20 0 1747M 20468 5040 S 0.7 0.1 2h01:02 /usr/bin/containerd
2854731 1000 20 0 1280M 399M 17880 S 36.9 1.3 1h57:52 unicorn worker[7] -E production -c config/unicorn.conf.rb
1721841 1000 20 0 592M 285M 5192 S 0.7 0.9 1h49:49 unicorn master -E production -c config/unicorn.conf.rb
2855284 1000 20 0 1287M 425M 18396 S 18.8 1.4 1h35:02 unicorn worker[3] -E production -c config/unicorn.conf.rb
2856414 1000 20 0 1223M 391M 19268 S 13.4 1.2 1h14:50 unicorn worker[2] -E production -c config/unicorn.conf.rb
2856478 1000 20 0 1207M 401M 21120 S 5.4 1.3 58:42.50 unicorn worker[5] -E production -c config/unicorn.conf.rb
2856503 1000 20 0 1215M 389M 18980 S 4.7 1.2 47:22.95 unicorn worker[1] -E production -c config/unicorn.conf.rb
1721581 www-data 20 0 69888 28636 13368 S 0.0 0.1 44:49.50 nginx: worker process
2857467 1000 20 0 1199M 385M 18112 S 4.0 1.2 39:23.87 unicorn worker[6] -E production -c config/unicorn.conf.rb
1721594 _apt 20 0 8479M 20036 18128 S 1.3 0.1 32:55.29 postgres: 13/main: walwriter
580 root 20 0 1747M 20468 5040 S 0.0 0.1 32:15.27 /usr/bin/containerd
总的平均负载是 5，但有时我仍然看到它上升到 8 或 9。
2 个赞
helmi
2022 年1 月 31 日 07:47
18
关于迷你分析器。我当时说的是整体加载时间。服务器响应时间（初始请求）通常在我们这边低于 10 毫秒。有时会稍高一些，但我上次检查时从未见过超过 20 毫秒。整体加载时间有时会高达 800 毫秒，极少超过 1000 毫秒。
只看一个地理区域，因为我们该区域以外的用户数量不多。
