1.3 机器准备：CVM 规格与多进程

日志管道的机器常被随手给——「先开台 4C8G 跑跑看」，结果要么内存浪费、要么高峰 OOM。本篇按管道负载画像给规格方法，并说明多进程结构怎么配，让这台机器跑得满又不拖累业务。管道的资源账要分两段算：采集段跑在业务机旁，目标是「存在感低」；汇聚段跑在专用 CVM，目标是「吞吐高」。两段规格逻辑完全不同。

负载画像：IO 密集而非 CPU 密集

日志管道大部分时间在做顺序读写：追加写 WAL、批量写 COS、顺序读文件尾随。CPU 只在解析与压缩时忙。所以规格的天平偏向磁盘吞吐与网络带宽，CPU 核数够用即可。一个常犯的错误是给管道配高主频 CPU，实际高峰期 top 看过去 CPU 才 20%——瓶颈根本不在那。

给配套云服务器规格做个示例：中型吞吐（5 万条/秒）的汇聚节点，4C8G 配足量磁盘吞吐即可；采集 agent 跑在业务机上，往往 1C 限配容器就够。规格更细的选型可参考 腾讯云云服务器文档，也可以对照 轻量服务器建站 的成本视角。

多进程结构：采集、汇聚、落盘三分离

管道跑稳的关键是结构分离：采集进程只读文件，汇聚进程做攒批压缩，落盘进程写 COS/CLS。三者的资源画像不同：采集吃文件句柄，汇聚吃内存与 CPU，落盘吃网络带宽。混在一个进程里，任何一段卡住都会拖死全局；分开后，每段可以独立限速、独立监控、独立重启。

进程间用有界通道连接，通道满了触发背压，天然保护上游不 OOM。通道的存在让「崩溃影响面」收窄：落盘进程崩了，采集和汇聚还能靠通道缓冲顶一会儿，重启落盘进程即可恢复，全程不丢。

进程数怎么配

CPU 核数与进程数的对应关系是新手最爱问的。经验值：采集进程按机器数走（每台一个），汇聚进程按压缩任务并行度走（通常 2~4 个），落盘进程按下游并发上限走（COS 并发写有上限，多了反而被限速）。不要简单地「一个核一个进程」——落盘进程多了会互相抢带宽。

真实部署还要考虑亲和性：把汇聚进程绑到固定核上，减少跨核缓存失效，对压缩这种 CPU 密集任务提升明显。另外提一句容器部署：如果管道跑在容器里，记得给容器设内存上限与 CPU 限额，否则容器编排器在节点压力时会优先 OOM 没有边界的进程，管道重启反而成常态。

规格的量化估算

给一个可直接套的估算示例。假设高峰 5 万条/秒、平均每条 500 字节、压缩比 5:1。那么：原始带宽 25MB/秒（入），压缩后 5MB/秒（出）；WAL 按峰值写 25MB/秒，需磁盘吞吐 ≥40MB/秒稳妥；内存按攒批 64KB × 64 批 ≈ 4MB 加上解析中间结构，留 1GB 足够；CPU 两核跑压缩即可。落盘 COS 并发按下游上限设，一般 8~16 个连接。

这个估算的要点是先算再买：不算清楚， 4C8G 与 8C16G 的差价全是浪费。上线后再按真实曲线回校一次，规格表就能越用越准。还有一个口径提醒：估算时别忘了扩容提前量。日志量随业务增长，每月环比 10% 很常见，规格按半年后的量买，能省掉中途被动扩容的慌乱。

部署形态：物理机、云 CVM 与容器

管道跑在什么形态上也影响规格。物理机磁盘吞吐最强但不灵活；云 CVM 弹性够用，磁盘吞吐按云盘类型走，增强型 SSD 才顶得住高峰 WAL；容器部署省事但要注意 IO 隔离差——同机其他容器狂读磁盘时，管道的写延迟会跟着抖。三种形态没有绝对优劣，常见组合是：汇聚节点用 CVM（稳定、磁盘可控），采集 agent 用容器（随业务机走、扩缩容方便）。

云盘选择上最常踩的坑是用了普通云盘跑 WAL：高峰期写延迟从毫秒级飙到百毫秒，吞吐直接腰斩，换增强型 SSD 才解决。这笔钱不能省。

部署清单：上线前逐条过

最后给一张部署自查清单，机器开了不是就完了：fd 上限调了吗？磁盘分盘做了吗？容器内存上限设了吗？监控装了吗？WAL 分区满了告警配了吗？五条全过完再上线，比上线后救火快十倍。

清单里最容易漏的是磁盘告警：WAL 分区一旦写满，管道要么停要么丢，两种都不可接受。告警阈值设在 80% 而不是 95%，留出归档清理的响应时间。清单全过完，这台机器才算真的「备好了」，后面的高吞吐才有地基可踩。

小结

管道机器按「磁盘吞吐优先、带宽次之、CPU 够用」配；多进程三分离让各段独立崩溃独立重启，通道背压兜底不丢；隐性账记得 WAL 分盘、fd 上限、带宽余量三件事。spec 表不是越大越好，而是让每段负载都跑在自己该有的资源上。云 CVM 与容器按段落位，清单五条过完再上线。多进程结构还带来一个长期红利：每段可以独立升级。采集层换实现、落盘层换存储，都不用停整条管道，灰度窗口小得多。 磁盘有两个隐性账。第一是WAL 与归档的写盘分离：两者都是顺序写，挤同一块盘会互相影响延迟，条件允许分两块盘或至少不同分区。第二是文件句柄上限：采集进程尾随几百个日志文件，默认的 fd 上限可能不够，部署时要调高。网络上同样有一笔：转发出去的数据量是原始吞吐的压缩后大小，带宽预算按压缩比反算，留 30% 余量防突发。

清单是死的，机器是活的——上线第一周每天对照监控曲线回看一次清单，会发现总有那么一条当初没考虑到的隐性项，补进去就是下一次扩容的依据。

踩坑提示

最典型的坑是规格只看 CPU 不看磁盘：团队买了 8C16G 的机器，配了一块普通云盘，结果高峰期 CPU 才 30% 吞吐就上不去——瓶颈是磁盘吞吐，加核完全没用。再一个坑是采集进程跑在业务机忘了限速：高峰期采集把磁盘 IO 抢光，业务接口全部变慢，排查半天才定位到旁边这个小进程。业务机上的采集必须有 IO 与 CPU 限额。

小结

管道机器按「磁盘吞吐优先、带宽次之、CPU 够用」配；多进程三分离让各段独立崩溃独立重启，通道背压兜底不丢；隐性账记得 WAL 分盘、fd 上限、带宽余量三件事。规格不是越大越好，而是让每段负载都跑在自己该有的资源上。

延伸阅读

• 通道背压的实现，见下一节 2.3。
• 压测单核吞吐天花板，见 5.1。
• 采集限速保护业务机，见 Node.js 云开发实战。
• 服务治理的资源隔离，见 Go 微服务实战。
• 存储分层与规格关系，见 MySQL 实战。