一台独服跑多个业务怎么分资源

机器买到手，第一件事往往不是庆祝，而是把几个业务全塞上去：主站、后台、数据库、缓存、定时任务、爬虫、文件存储，一样不落。头两周运行得好好的，一个月以后开始互相拖，页面开了十几秒、数据库偶尔卡死、备份一跑业务就超时。到底是机器不够用，还是分配方式出了问题，这篇按 CPU、内存、磁盘三条线说清楚，也讲讲什么时候该老老实实拆机。

一台机器塞多个业务会撞在哪

撞点集中在四类资源。处理器被一个吃满核的任务占住，其他进程排不上队；内存被几个服务各占一块，谁都不肯释放，压力一大开始交换；磁盘的随机读写被备份和日志写满，数据库读一次要等几十毫秒；网络被下载和同步任务占住，前台请求开始排队，日志里全是超时和重试记录。

这四类里最隐蔽的是磁盘。处理器和内存吃紧，面板上一眼就能看到占用率，磁盘的等待时间藏在 IO 等待里，表现出来只是接口变慢，很少人第一反应会去查盘。第二隐蔽的是内存回收，被缓存和临时表占住的内存，空闲时看着无所谓，真到峰值就变成换页，机器整体卡顿，日志里却只有零散的超时，很难定位到具体业务。

另有一类是互相唤醒的连锁反应。备份任务占满磁盘，数据库查询变慢，应用层超时重试，重试又加重数据库负载，一路滚下去整台机器像雪崩，这种故障排查时最费时间。

能不能塞，取决于业务的峰值是否重叠。白天跑前台、夜里跑备份，两套业务的时间错开，共用一台机器问题不大；两个业务的高峰都在晚上八点，挤在一起再宽的配置也扛不住。

所以第一步不是买什么机器，而是把所有业务的峰值时段画在一条时间轴上，看它们能不能错开。能错开的合并部署，错不开的就得分开，这条判断比配置参数重要得多。

CPU 超分的红线画在哪

虚机层面常见的做法是超分，一台二十四核的机器开三十个虚拟核心出去，靠的是各虚机不会同时满载。轻量业务超分两倍还能接受，跑数据库和编译任务超分到 1.5 倍就开始互相等。超分比的不是核数总和，而是同一时刻真正在跑的线程数，统计里该看的是就绪队列，队列一长就说明分多了。二十四核跑到四十个线程，轻量站点还能撑，数据库这种持续吃核的业务就明显吃力。

安全的做法是按峰值预留。统计各业务过去一周的最高负载，把峰值加起来再留两成余量，超分只在这种有数据支撑的前提下做，凭感觉分配迟早出问题。预留的方式按业务类型分档，数据库和实时接口给足三成余量，静态站和定时任务给一成即可。分档之后扩容的判断也有了基准，哪一类先撑满就先动哪一类。统计周期至少拉一周，只看某一天的高峰容易低估。

容器侧还要注意限制。给每个容器设定 CPU 配额和共享权重，避免某个批处理容器把核全吃掉，让前台容器排队。限制写进编排配置里，比出事之后再人工调度可靠。配额外再设上下限，下限保证容器不会被饿死，上限防止单个容器拖垮整台机器。批量任务安排在夜里跑，白天只留基础配额，两边互不干扰。

内存怎么切才互不拖累

内存是最容易分错的资源。数据库的缓冲池、Redis 的上限、应用的堆、系统缓存，几项加起来必须小于物理内存的七成左右，剩下的三成留给页缓存和临时峰值，这个比例留不够，压力一来就交换。

数据库的缓冲池不要按「尽量大」来配。给 128GB 的机器，缓冲池配到 60GB 到 70GB 就算合理，再多会和页缓存抢，反而拖慢读取。

缓存服务要显式设置上限。不设上限的缓存会一路吃掉剩余内存，被系统的交换策略挑中后整体开始换页，表现是整台机器抖，问题却出在缓存这一块。

应用的堆要按业务峰值配，别按开发机的经验值。中小站点给两到四 G 通常够，跑批处理和图片处理的要给到八 G 以上，堆太小会频繁整回收，CPU 空转。

虚机的内存分配要算上开销。每台虚机除了分配给系统的内存，还要给虚拟化层留一点余量，八 G 的虚机实际占用可能接近九 G，十几台加起来差出好几 G，到头来就卡在这点余量上。

留一部分空闲不是浪费。长期跑在九成以上内存占用的机器，出一次峰值就可能触发大面积换页，留两成余量相当于给自己买了缓冲时间和排查窗口。监控要盯不该放弃的指标，内存可用值、交换使用量、页缓存比例，这三项比单看占用率有效，尤其是交换量一旦有持续增长，就说明分配已经不合理了。

想省内存也有手段。静态资源交给反向代理缓存、日志写入改成异步、把不常用的服务停掉、图片压缩后再存。这些动作比继续加内存便宜，很多时候做完问题就消失了。128GB 这一档的机器在大内存独服清单里能直接对照，按上面的比例切完，剩下的余量刚好够峰值。够不够用，先按这个方法算一遍再决定要不要换机器。

磁盘 IO 是最先爆的那一环

机械盘和固态盘的随机读写差着量级。同样是 128GB 内存的两台机器，一台配 800GB SSD，一台配 6TB SAS 机械盘，跑数据库和大量小文件读写的表现完全不同，前者几千 IOPS，后者一百多。随机读写的差距不是靠内存能补回来的，数据库的索引扫描和事务日志都吃这个能力，机械盘放在这上面就显得很吃力。容量再大也补不回随机访问的延迟，选盘之前先想清楚业务到底在读写什么。

所以按用途选盘：数据库、缓存、容器镜像、代码编译这些吃随机读写的业务放 SSD；备份、归档、素材库、日志冷存储这些吃顺序大文件放机械盘，容量便宜，顺序读写也跟得上。看清楚自己业务的读写比例，随机为主的别贪容量，顺序为主的别多花钱买速度。

混装的时候要把 IO 隔开。数据库和备份放同一块盘是典型事故，备份一跑数据库就卡，办法是分盘、加独立的备份盘，或者限速备份的写入带宽。再看队列深度和等待时间，而不只是利用率。磁盘利用率到七成、平均等待上到二十毫秒，就说明已经到了该处理的节点，等到百分之百再动手就晚了。把这三项做成监控面板，容量、等待、队列一起看，才能判断瓶颈在盘还是在上层程序。看完这三项再决定是加盘还是换机型，比凭感觉拍板稳得多，也能少走一遍返工。

容器和虚机怎么混着跑

虚机隔离强，适合跑需要独立内核、独立系统版本的老程序，也适合做多租户环境；容器启动快、开销小，适合跑无状态的 Web 服务和定时任务。一台机器上两种都跑很常见，关键是分工清楚。

资源归属要明确。虚机分配的是固定内存和虚拟核心，容器用的是共享的配额和权重，两类混跑时先把虚机的预留扣掉，剩下的才给容器分，顺序颠倒就会互相踩。

网络要隔离。容器默认的网桥和虚机的虚拟网卡在同一个宿主机上争抢带宽，给容器限速、给虚机单独设流量策略，避免某个容器的下载任务把整台机器的出口打满。

存储要分层。容器镜像和非持久数据放一层，虚机磁盘放一层，共享的素材和备份放第三层，各层用不同的盘，某一层写满不会影响其他层继续跑。

编排工具能帮上忙但要慎用。单机环境装一套完整的集群编排，本身就要吃掉几 G 内存和一部分 CPU，业务规模不大时反而不划算，简单的手工配置加上监控更实在。

版本和依赖要管住。同一个宿主上跑多个容器，基础镜像版本不一致会带来补丁和漏洞管理的麻烦，定一套统一的基础镜像，升级的时候一次改完，比逐个容器修补省事。

日志要集中。容器和虚机的日志分散在各个目录，出问题时到处翻，把日志统一收进一个位置，按业务打标签，排查时按时间线看，一小时内能定位问题。

备份要分开做。虚机整机快照、容器配置和数据卷、宿主机的系统配置，三类备份策略不一样，混在一起做会漏掉配置和密钥，真恢复的时候才发现少东西。

什么时候该拆机器

第一个信号是持续高负载。处理器长期在八成以上、内存长期在八成五以上，加配置也追不上业务增长，就该考虑拆机，把业务分到两台上，每台的余量都重新回来。

第二个信号是故障影响范围变大。一台机器承载的业务越多，一次故障波及的面越广，当停机一分钟损失的钱超过多买一台机器的成本，拆机就是划算的。算这笔账时别只算带宽和机器价，停机的客户流失、人工排查的时间和修复窗口都要折进去，只算机器差价往往会得出相反的结论。

第三个信号是安全边界需要。不同客户、不同等级的站点混在一起，一旦被入侵就全线下沉，按客户或者按业务拆分，本身就是一道防线。第四个信号是运维排期互相打架，一个业务要重启、一个要升级、一个在跑批处理，凑在同一台机器上每次都得协调窗口，拆开之后各自安排时间，人力成本立刻降下来。

拆之前先算清迁移成本。数据要搬、域名要切、缓存要预热，一次迁移通常要占用半个工作日的精力，把迁移窗口和回滚方案先写好，再动手。渠道里适合做合并部署和拆机后扩展的机型，从云途香港独服各档清单里能一眼对照。128GB 内存那一档的 DS.ES.D 和 HK.DS.S 适合先合并上量，真到了要拆的时候，再按业务类型分别挑便宜的入门档，一台管前台一台管备份，比硬撑在一台高配机上更好管。