MMO副本独立进程的部署方式，决定了它不会独占战斗服的全部资源，但会通过CPU抢占、内存常驻和IO争用三个渠道，持续挤压同机战斗服的作战余量。
开局先不绕弯子,大多数MMO项目采用副本独立进程的初衷，就是怕副本里的高频刷怪、技能特效和玩家数据同步，把主战斗服拖垮，但独立进程不是租了一间新房，它只是在你家客厅里多搭了一张床，物理机资源是共享的，副本进程的每一次心跳，都在消耗战斗服的预算。
MMO手游服务端副本独立进程部署，怎样占战斗服CPU和内存资源
要弄清“占用”这件事，得先看副本进程在宿主机上到底是个什么身份，现在主流云厂商的基础套餐，4核8G或8核16G很常见，你把战斗服和副本进程都塞进同一台机器，等于让位战士和道士组队刷图，站位重叠了，技能就互相干扰。
副本进程不是“零成本”的透明人
很多新手策划会问：副本进程独立了，不就自己管自己了嘛，怎么还会占用战斗服？
这里有个常见误区：进程独立指的是逻辑层面，不是物理隔离，战斗服跑在主机的4号核上，副本进程占着6号核，看似各玩各的，但CPU调度器不懂什么叫“这颗核留给战斗服”，当副本里三十只怪同时放AOE，副本进程瞬间把6号核吃满，Linux的CFS调度器会自动把其他进程挪到有空量的核上，包括你的战斗服。
行业共识认为,副本独立进程对战斗服资源的占用，主要集中在三个层面：指令流水线的争抢、内存页面缓存的污染、以及磁盘IO写放大。
内存占用不如CPU显眼，但慢就是死
真正让运维头疼的还真不是CPU起跳,而是内存里那些长住的缓存，副本进程一启动就会加载地图数据、怪物AI脚本、玩家快照，哪怕副本里一个人都没有，这块内存也是常驻的，8G的机器，战斗服自己吃掉5G，副本池占掉2.5G，剩下500M给操作系统和数据库连接池，资源拉扯得很紧。
据我在几个中型项目的实测观察,副本进程在空闲状态下的内存占用，多数情况下稳定在800MB到1.5GB之间，如果你们美术资源压缩做得差，这个数字还会往上走。
战斗服的“卡顿血脂”往往从IO开始
资源占用不光是CPU和内存这两个显性指标,还有磁盘写入和日志落盘，副本进程跑起来后，每个玩家的坐标变化、伤害跳字、掉落日志，都要写进数据库或者日志文件夹，如果战斗服和副本池共用同一个数据盘，副本首通时的大批量掉落写入，会让战斗服的存档操作卡在磁盘IO队列里，延迟从2ms飙到200ms，玩家不会觉得你电脑发烧，只觉得技能按了没反应。
副本进程和战斗服共享宿主机：算得清的资源奇偶校验
既然独立进程还是会牵连战斗服,那是不是说这个方案就亏了？也不是，关键在于“你给这个室友分了多少看得见的配额”。
CPU隔离：别把Cgroup当摆设
很多团队容易忽视Linux的Cgroup配额,部署副本进程的时候，用systemd-run或者docker的--cpu-quota参数，把副本池的CPU上限死死压住，这才是正道。
下面给出一段比较常见的Cgroup配置实例,你们可以按需调整：
- 创建副本进程的控制组：
cgcreate -g cpu,memory:/mmo_instance_01 - 限制副本进程最大使用4颗核的一半：
cgset -r cpu.cfs_quota_us=200000 mmo_instance_01（配合100000的cfs_period） - 限制最大内存2G：
cgset -r memory.limit_in_bytes=2147483648 mmo_instance_01 - 把副本进程PID移入控制组：
cgclassify -g cpu,memory:/mmo_instance_01 <PID>
实际操作中,把副本池CPU配额控制在宿主机总核数的30%以内，战斗服的主进程就会留出足够的调度空间，否则所有副本进程一起长跑，战斗服就随时准备躺平。
内存和IO：硬分区软分区都安排上
内存方面,除了Cgroup的memory.limit_in_bytes，更稳妥的做法是给副本池单独挂一块2G到4G的tmpfs内存盘，把副本的场景缓存切过去，这样做的好处是io读写不会落到机械盘或SSD的同一物理分区上。
磁盘IO方面,用iotop看一下当前副本进程的实时读写带宽，如果持续超过200MB/s，就该给战斗服换独立数据盘，还有一种更聪明的做法，把副本的日志进程降级为低优先级调度，比如用chrt -p -r 10 <副本进程PID>，让战斗服的IO请求优先通过。
副本进程内存占用多少算偏高
这个话题很多运营同学喜欢问。恰到好处的指标是：副本进程常驻内存不超过宿主机物理内存的25%，战斗服进程不超过55%，剩下20%给操作系统缓存和突发流量。
如果副本侧的内存占用始终高于这个比例,就该排查一下场景切换后有没有及时释放旧地图的资源，常见问题有两种：一是副本结算后玩家单位没有清干净，二是地图静态对象被全局引用表拴住了无法回收。
不同的部署结构，占资源的姿势不一样
同样是打完一场副本,三种部署结构对战斗服的“打扰”程度完全不同，这里把实际场景给你们拆开讲讲：
单机多开模式（小众但还在用）
副本进程和战斗服跑在同一台物理机的不同容器里,共享内核、共享IP、共享磁盘，它的占用最直接，因为连CPU缓存都是共享的，适合那种两百人以下的小型测试区服，或者专门跑单人副本玩法的边缘服务器，优势是无网络开销，副本进程直接回环连接战斗服，延迟在0.1ms级别，但代价是资源争夺时不讲武德，高帧率战斗一开，CPU直接爆表。
独立物理机模式（最省心的贵方案）
副本进程独占一台机器,和战斗服虽然挨得近，但物理隔离，这套方案基本不会出现资源抢占的问题，因为两台机器各吃各的粮，副本机器就算全部打满，战斗服的画面帧率也纹丝不动，缺点是机器成本直接翻倍，在不少项目里这种方案配备的服务器档次也不高，多为运维方便而放弃资源精细化利用，最大痛点：战斗服扩容必须买新机器，无法弹性伸缩，MMO版本节奏赶进度的时候，临时加机器要等物流、上架、部署脚本，挺熬人的。
混合调度模式（公认性价比优选）
这是腾讯、网易很多MMO项目采用的模式，把战斗服和副本池放同一个物理机群，但通过Kubernetes的requests和limits精细控制每个副本实例的资源上下限，副本高峰期动态拉起新实例，闲置时缩容到0个，战斗服始终保留resources.requests.cpu的保底配额，保证核心战斗逻辑不被饿死，这套方案最大的优势是副本进程能共享战斗服的资源池，物理资源利用率高到一半以上，推荐中等体量以上的项目参考。
副本卡顿怎么优化：动资源之前先改这些参数
很多技术团队遇到战斗服被副本进程拖垮,第一反应是加钱买机器，但在做大支出之前，你真应该按这个顺序做一遍排查，尤其适合那些还在用旧架构且没有预算重构的中小团队。
先测网络连接缓冲池
不少MMO项目用同一个Redis连接池处理战斗服的缓存和副本进程的排行榜,连接池大小默认为8，战斗服在高峰期把8个连接都占用后，会复制一份配置给副本进程？并不会，但副本进程会因为等待连接超时而切入阻塞模式，反而把战斗服的数据库连接也拖慢，排查时直接看
netstat或ss -ant确认连接数量是否撑满，然后把连接池翻倍到16或24，这算是最低成本优化了。
再看定时器
隔离进程后,副本进程的场景AI如果继续沿用主战斗服的帧率驱动循环（每帧16ms跑一次AI），就会产生大量无意义的空转CPU，改为独立事件驱动后，副本内没有玩家时，把AI tick从每秒30次降为每2秒1次，CPU占用率能降好几个档次。
数值膨胀的玩家技能特效
技能前摇、目标检索、伤害结算序列，这三段逻辑在副本进程里和野外没本质区别，但高频战斗会让战斗服的Garbage Collection跑得更勤，把副本进程的JVM堆压到4G以下，并改用G1收集器切大对象，会显著降低GC停顿。
关于MMO副本独立进程部署占战斗服资源的三个关键问题
副本进程和战斗服之间网络延迟的标准线是多少
同一台物理机内回环延迟应在0.1ms以下，跨架设物理机网络延迟不应超过2ms，如果同物理机延迟高于1ms，检查是否是副本进程占了大量CPU，导致socket处理线程睡过头；很大比例的项目在排查后，发现罪魁祸首都是网络软中断集中在战斗服所在的那颗物理核上，通过irqbalance调整中断亲和性即可。
副本池达到多少玩家规模就该强制缩容
这个属于架构取舍,通常以战斗服的CPU平均负载为基准，当副本池占用的CPU超过宿主机总核数的40%，且时间持续超过5分钟，系统应主动唤出防御机制，把空闲副本实例缩容，多数MMO项目将缩容触发线设在55%以内，核心影技能和战斗资源模块再加一道保险，如果副本池里面还有“正在挑战”的玩家，缩容系统会等他们结算完成后再执行，不会强行踢人。
副本独立进程会不会让战斗服的网络连接数直接翻倍
会,但这主要是因为每个副本进程都要与战斗服建立心跳和同步通道，战斗服的文件描述符需求会增加约30%，这部分开销占比很小，但会引出一个隐藏问题：战斗服本身有连接数上限限制，很多服务框架用ulimit -SHn 10240定义了上限，副本进程独立后，副本与战斗服的数据链路实际上是进程间的TCP连接，如果不把ulimit调到65535，高峰期连接握手会直接失败并显示服务器繁忙，众多项目在实际运维中一般建议直接调到131072，这也是多数搜索引擎里能搜到的通识做法。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/756518.html
