2026 郑州机房还挂着 L5520 和 E5640：这类老至强现在还能扛什么活

十年前的 CPU 还在报价单上

Xeon L5520 是 2009 年第一季度发布的型号，Xeon E5640 紧跟着在 2010 年发布。从那时到 2026 年，中间隔了十六年，隔了 Sandy Bridge、Haswell、Skylake、Ice Lake，一直到今天主流的 Sapphire Rapids 与 EPYC Genoa 这几代平台，CPU 换了五六茬，内存从 DDR3 走到 DDR5，系统盘从 SATA SSD 换成了 NVMe。就是这样两颗十六年前的处理器，到今天仍然挂在国内机房的现售清单上，而且不是按清仓价挂的。

一万网络郑州机房在售的四档老平台配置里，L5520 双路的两档是月付 800 元和 550 元，E5640 双路的两档是 900 元和 750 元（以上均为官网明示价，实际以官网实时价为准）。这个价格带本身就很说明问题：它既不是白送，也不是按新机型的定价逻辑在卖。

这不是产品页忘了更新。一款 2009 年的 CPU 能在 2026 年的在售清单上留着，说明它每个月都在被真实租出去，且续租率撑得住它占的机位和电费。卖不掉的型号早就被下架了，机房不会为情怀留机位。

老 U 卖的从来不是算力。这两颗 CPU 的单核性能和今天的主流服务器 CPU 根本不在同一个量级，拿它跑任何吃单线程的任务都会很难看。它卖的是另外三样东西：一台真实独占的物理机、一条长期稳定的带宽、一个足够低的月付门槛。

决定这台机器生死的不是型号老不老。同一个机房里 L5520 和 E5640 的机器同时在卖，说明"这颗 U 是哪一年发布的"并不是采购时真正要回答的问题。真正要回答的是你的负载吃的是单核性能、是内存带宽，还是只要一台长期在线、不掉线、带宽稳定的独立机器。

它的退役时间点是可以提前算出来的。CPU 持续高位、内存开始吃 swap、业务依赖的运行时开始要求新指令集——这三条线任何一条被踩穿，就该换，而且通常不是原地升，是换机型重新上架。

这篇文章只讨论一件事：这台老机器身上剩下的价值具体是什么，什么活它能干，什么活必须换机器。

先给这两颗 U 定个位：它们到底是哪一代的东西

要判断一台机器能干什么，先得知道它的硬件底座停在哪一年。L5520 和 E5640 经常被放在一起说，因为它们共用同一套平台，但严格讲它们不是一个核心代号。

L5520 属于 Nehalem-EP（核心代号 Gainestown），45nm 工艺，LGA1366 封装，2009 年发布。四核八线程，基础频率 2.26GHz，三级缓存 8MB，TDP 60W，是当年主打低功耗的"L"系列。它的内存控制器是三通道 DDR3，官方支持的内存规格到 DDR3-1066，单路内存上限在 144GB 这个量级。指令集方面，它支持到 SSE4.2，不支持 AVX，也不支持 AES-NI。

E5640 属于 Westmere-EP（核心代号 Gulftown 家族），32nm 工艺，同样 LGA1366，2010 年发布。也是四核八线程，基础频率 2.66GHz，三级缓存 12MB，TDP 80W。内存同样三通道 DDR3，官方规格可以到 DDR3-1333，单路内存上限在 288GB 这个量级。它比 L5520 多出的是 AES-NI 硬件加解密指令。

所以这两颗 U 共同的技术画像可以这样描述：LGA1366 双路平台、Nehalem/Westmere 这一代微架构、每颗四核八线程、三通道 DDR3 内存控制器、QPI 互连、SATA 存储接口、指令集止步于 SSE4.2。双路配满之后，整机是 8 核 16 线程——注意是 8 核，不是 16 核，这个数字在后面判断负载时要反复用到。

有几个衍生结论必须提前说明白，因为它们直接决定了这台机器能接什么活。

没有 AVX，也没有 AVX2。AVX 是 Sandy Bridge 时代（2011 年）才引入的，AVX2 要等到 Haswell（2013 年）。这意味着任何在编译期就要求 AVX/AVX2/FMA 的软件，在这台机器上要么跑不起来，要么必须退回不带这些优化的旧版本。这不是性能高低的问题，是能不能启动的问题。

内存带宽是硬天花板。单路三通道 DDR3-1066 的理论峰值带宽按"通道数 × 频率 × 8 字节"换算约 25.6GB/s，DDR3-1333 约 32GB/s，实际可用带宽还要低于这个数。作为对比，今天主流双路平台的内存带宽是这个数字的几倍到十几倍。凡是靠大量顺序扫描内存吃饭的负载，在这台机器上会明显感觉"CPU 没跑满但就是慢"。

双路意味着 NUMA。两颗 CPU 各带自己的三通道内存，跨路访问要走 QPI，延迟和带宽都打折。所以"16 个线程随便用"是一种错觉——进程如果频繁在两颗 CPU 之间被调度，内存访问会跨路，性能会掉。真要压榨这台机器，得做 NUMA 亲和绑定，让服务固定在一路 CPU 和它直连的内存上。

跑分数据本文不引用。判断一台老机器够不够用，最可靠的办法是把你自己的业务放上去跑一周，看单线程任务的耗时和内存占用曲线，而不是看某个通用 benchmark 的分数。

老平台真正剩下的三样东西

把 CPU 性能这一项从价值清单里划掉之后，老平台上剩下的东西反而变得很清楚。它不是"便宜的差机器"，它是"用旧硬件的价格买到了几样新硬件并不自动附带的东西"。

第一样：物理机独占

这是最容易被低估的一项。这台机器上的 8 核 16 线程、8G 或 16G 内存、那块 SSD，全部是你独占的，没有邻居在跟你抢。你在上面跑一个定时任务，不会因为宿主机上有人跑了个大查询就跟着卡；你挂载的文件系统、你改的内核参数、你装的冷门内核模块，都不会有人来跟你协调。虚拟化平台上那些"吵闹的邻居""IO 抖动""CPU steal 时间"的问题，在这台机器上从根上不存在。

对很多业务来说，独占这个属性本身就是刚需：需要改 sysctl 参数、需要加载特定内核模块、需要跑特权容器、需要接硬件加密狗或特定的 USB 设备、需要自己控制 iptables 规则集、需要装一个必须独占端口的老服务。这些事在共享型虚拟主机和某些受限的云主机上都做不了，在一台物理机上都是免费的。

第二样：一条固定、可预期的带宽

郑州机房这批老机型的带宽有两种写法：一种是 100M 共享，另一种是"10M 独享 + 100M 共享""20M 独享 + 100M 共享"这种双带宽结构。后者值得单独说一句——它真正的价值不是"总带宽更大"，而是有一条不抢的保底通道。

对内网工具、备份同步、监控上报、跳板机这类负载来说，带宽的峰值并不重要，重要的是"每天凌晨两点那 20 分钟的同步窗口里，我能不能稳定拿到一个确定的速率"。保底通道解决的就是这个确定性：它保证你最差也有 10M 或 20M 可用，而共享部分提供的是白天的突发余量。这种"下限确定、上限有余"的结构，恰好是后台类业务最需要的形态。

第三样：低门槛的月付

550 元到 900 元这个月付区间（官网明示价，以官网实时价为准），意味着一件事：一台长期在线的独立物理机，一个月的成本大约等于一顿饭钱到一次团建的费用。这个门槛让很多"本来不值得开一台机器"的需求变得值得了。

举个典型场景（以下为典型部署思路，并非特指某一真实客户）：一个三人小团队需要一台常年开着的机器，用来放内部 Wiki、跑 GitLab Runner、做异地备份的目的端、挂几个定时巡检脚本。这四件事任何一件单独拿出来都不值得开一台机器，但合在一起放到一台 550 元的物理机上，成本就被摊薄到几乎不用讨论的程度。这就是低门槛月付创造的价值——它把"要不要有一台自己的机器"从一个预算决策变成了一个随手决策。

还有一个不能忽略的点：这类存量机型的长期可续性。新机型的配置可能半年一变，你今天租的型号明年可能就下架了，续费时被引导换机型；而一批已经在机房跑了十几年、备件和机位都稳定的老机型，反而是那种"我可以不动它，让它一直待着"的选择。对一个只想把某件事稳定跑三年不想折腾的人来说，这个稳定性是有价的。

先说钱是怎么分的：四档配置里，价差买的是什么

在讨论能干什么活之前，先把价格结构拆清楚，因为这里有个反直觉的地方。四档配置摆在一起看：

01 档（郑州多线机房服务器）：L5520*2 / 8G / 240G SSD / 100M 共享 / 1 个 IP，￥800 元/月。
02 档（郑州联通中原）：E5640*2 / 16G / 180G SSD + 1T HDD / 100M 共享 / 1 个 IP，￥900 元/月。
03 档（郑州联通中原服务器）：L5520*2 / 8G / 160G SSD 或 1T HDD / 10M 独享 + 100M 共享 / 1 个 IP，￥550 元/月。
04 档：E5640*2 / 16G / 160G SSD + 1T HDD / 20M 独享 + 100M 共享 / 1 个 IP，￥750 元/月。
（以上均为官网明示价，实际以官网实时价为准。）

01 档和 03 档的 CPU、内存完全一样，都是 L5520*2 + 8G，硬盘一个是 240G SSD、一个是 160G SSD，带宽一个是 100M 共享、一个是 10M 独享 + 100M 共享。结果是 01 卖 800 元，03 卖 550 元——便宜的那一档反而多了一条 10M 保底通道。80G 的 SSD 容量差不可能撑起 250 元的月差价。这 250 元买的不是 CPU，也不是硬盘本身，而是硬盘容量与机房线路、带宽结构打包在一起的组合方式：01 是四档里唯一标注了"多线机房"的那一档，多线接入的成本和纯联通节点的成本本来就不在一个口径上。

反过来看，01 到 02 是四档里唯一一次"钱确实主要花在硬件上"的升级：加 100 元，CPU 从 L5520*2 换成 E5640*2（2.26GHz 到 2.66GHz，三级缓存 8MB 到 12MB，还多出 AES-NI），内存从 8G 翻到 16G，硬盘从 240G SSD 变成 180G SSD + 1T HDD。这一档加价买到的是实打实的硬件规格。

03 到 04 同理：加 200 元，CPU 换成 E5640*2、内存翻倍到 16G、独享从 10M 提到 20M，另外带一块 1T HDD。

把这几组对照放在一起，结论很干净：同一机房内部的加价（01→02、03→04）买的是硬件规格；跨档的价差（01↔03）主要体现在机房线路和带宽结构上。CPU 型号老不老，从来不是这四档价格的主要变量。这也从价格的侧面印证了本文的核心判断——老平台的价值不在算力。这一点和"在同一个报价单里怎么选档"是两回事，本文关心的是这台机器本身值不值。

它还扛得动的活

判断一台老机器能不能接某个活，用一句话概括：看这个活的瓶颈在哪。如果它的瓶颈是网络 IO、是磁盘空间、是"有没有一台机器在那儿"，而不是 CPU 单核和内存带宽，那 L5520 双路这台机器基本都能扛。

内网工具与跳板机

跳板机、堡垒机、内网 DNS、内部 Wiki、工单系统、内网镜像源，这类负载的共同特点是并发低、CPU 占用长期在个位数、内存占用稳定且不大、但对"一直在那儿"的要求极高。一台机器常年 3% CPU 使用率，就是它最合适的工作状态。双路 16 线程在这种负载下是纯粹的余量，8G 内存也完全够（一个跳板机上跑 sshd + 一个轻量 Web 服务，常驻内存通常不到 2G）。

这里反而有个加分项：物理机独占意味着你可以自己改 SSH 配置、装 auditd 做审计、配 fail2ban、限制源 IP，不用担心这些规则跟别人冲突。

备份与归档节点

备份目的端是老平台最经典的用途之一。它的瓶颈是磁盘容量和顺序写入，不是 CPU。1T HDD 那块盘就是为这种活准备的：每天凌晨从生产库上 rsync 或者拉一份逻辑备份过来，按日期目录归档，保留三十天。压缩这一环节要不要在这台机器上做，取决于你的窗口时间——gzip 是单线程且吃 CPU 的，在这颗 U 上压缩几个 GB 的数据会比较慢；如果备份窗口紧张，更合理的做法是在源端压好再传过来，或者改成多线程压缩工具并把线程数控制在 4 以内。

监控采集端

Prometheus 采集端、日志收集 agent、Zabbix proxy、SNMP 轮询器，这类负载的特征是"持续的小流量写入 + 定时的大批量落盘"。它吃的是磁盘 IOPS 和内存中的时序缓存，CPU 消耗主要在序列数量而不是采集频率上。在 8G 内存的机器上跑一个采集端，把采集目标控制在几百个以内、本地保留周期压到 15 天以内，通常是稳的。要注意的是别在这台机器上同时跑 Grafana 和一个本地时序库的高基数查询——那会同时打穿内存和 CPU 两条线。

静态资源源站

图片、JS、CSS、安装包、软件镜像这些静态文件，Nginx 发出去几乎不消耗 CPU，消耗的是带宽。这类活对老平台来说是最舒服的场景之一：240G SSD 那一档（01）装得下不小的资源库，SSD 的随机读性能让小文件并发不至于卡在磁盘上。如果前面再挂一层 CDN 把大部分请求挡掉，源站这边实际承接的回源流量会更小。

低频 API 与内部接口

每秒几请求到几十请求量级、单次请求逻辑简单、不做复杂计算的接口服务，老机器扛得住。这里的关键约束是响应时间不要太苛刻——如果单次请求要做几百毫秒的 CPU 密集计算，那在老 U 上会拉长到秒级；如果只是查一次库、拼一下 JSON 返回，那完全没问题。另外要控制并发连接数下的进程/线程规模，8G 内存不要开几百个 worker 进程。

开发测试环境

开发联调环境、CI 的 runner 从节点、给外包同事开的临时登录环境、产品演示环境——这些环境对性能没有要求，对"隔离"和"便宜"有要求。一台独占的物理机拿来当测试环境，最大的好处是你可以随便折腾：随便装依赖、随便改系统配置、随便把它搞崩了重装，不会影响任何生产东西。这个"随便折腾"的自由度，是老平台低门槛带来的隐形福利。

把上面这些场景汇总成一张判断表：

它扛不动的活：这四类别往上放

表里有四类已经给了否定结论，这里把原因讲透，因为这几类是最常见的误用。

吃单核性能的活

数据库主库、编译构建、加密解密、图片视频转码、实时压缩，这些活有一个共同点：任务无法有效并行，或者并行之后每个线程仍然要独立完成大量计算。在这类负载上，CPU 的代际差距会被直接翻译成响应时间。同一条 SQL，在新平台上 20 毫秒返回，在这台机器上可能是 200 毫秒——不是因为机器忙，是因为单核一次能干的活就这么多。数据库连接数一上来，线程池排队，延迟呈非线性上升。

加密解密这块有个例外要说清楚：E5640 带 AES-NI，做 AES 类的对称加解密（比如 HTTPS 握手后的批量传输加密、磁盘加密）并不慢；L5520 没有 AES-NI，同样的活会走纯软件路径。所以如果你要在老机器上跑大量 TLS 或 VPN 类流量，选 E5640 那两档是有实际意义的，这不是型号玄学，是指令集的有无。

吃内存带宽的活

大表的全表扫描、内存数据库的热数据访问、向量检索、大规模排序、科学计算、日志的实时聚合分析——这类活的特征是 CPU 使用率可能只有 50%，但就是慢，因为瓶颈在内存控制器上。三通道 DDR3-1066 的那 25.6GB/s 理论峰值，是这条路上谁也绕不过去的天花板。而且双路 NUMA 结构下，进程跨路访问内存性能还会再打折。

要跑虚拟化的活

在一台 8G 或 16G 内存、8 核 16 线程的机器上开 KVM 或者跑一堆虚机，是典型的不自量力。先不说 CPU 特性缺失会让不少新版客户机操作系统装不上或跑不稳，光是内存这一项就判了死刑：宿主系统自己留 1.5G，剩下 6.5G 分给三台虚机，每台 2G，任何一台想跑个像样的服务都不够。虚拟化的价值在于资源超卖和隔离，而超卖的前提是有足够的资源池，老平台没有这个池子。

依赖新指令集的活

这一条是最硬的墙，因为它不是"慢"的问题，是"跑不起来"的问题。典型情况：新版数据库或向量检索库在启动时检测 CPU 特性，缺 AVX/AVX2 直接拒绝启动；某些机器学习推理框架的分发版本只提供 AVX2 编译产物；某些语言运行时或加密库在新版本中把 AVX 作为最低要求。遇到这类情况，你连"忍一忍慢一点"的选项都没有。

判断方法很简单，在机器上执行 lscpu 或者 grep -o -E 'avx|avx2|fma|aes|sse4_2' /proc/cpuinfo | sort -u，看输出的 flags 里有没有那些指令。L5520 和 E5640 两个平台上，你都不会看到 avx、avx2、fma；E5640 上能看到 aes，L5520 上通常看不到。这个检查应该在上架第一周就做一遍，而不是等到部署失败时才发现。

8G 和 16G 内存在 2026 年意味着什么

内存是这批老机器上最容易踩坑的一项，因为很多人对"8G"这个数字没有时代概念。2010 年，8G 是台像样的服务器；2026 年，8G 是"刚好够跑一个东西"的水平线。这笔账得拆开来算。

先看系统本身要吃掉多少。一套主流的 Linux 服务器发行版，装完最小化系统、跑起来 sshd、systemd-journald、rsyslog、cron、一个监控 agent，常驻内存通常在 500MB 到 1.5G 之间，具体取决于发行版和开了多少服务。这部分是固定成本，剩下的是可支配的。

再看一个应用要多少。Nginx 十几个 worker 进程，几十 MB；PHP-FPM 开 20 个子进程，可能 600MB 到 1G；一个中等规模的 Java 应用，JVM 堆给 2G，加上堆外和元空间，实际常驻可能接近 3G；MySQL 或 MariaDB 想跑得像样，缓冲池通常要给到 2G 以上；Redis 如果数据集有 2G，那它的常驻就是 2G 多，而且做 RDB 快照时 fork 出来的进程在写时复制机制下还需要额外的内存余量——这是最容易被忽略的一点，工程上的通行做法是给 Redis 留出数据集本身 50% 以上的内存余量，具体数值以实际负载下的观察为准。

把这些加起来，8G 机器的现实位置就很清楚了：它能稳稳地跑"系统 + 一个主服务"，勉强能加一个小服务，绝对跑不了三个中等规模的服务。如果你打算在 8G 的机器上同时放 Web、数据库和缓存，那第一周可能没事，第二周开始就会出现内存压力，表现是响应变慢、日志里出现 OOM 相关记录、进程被系统杀掉。

16G 的位置则不同。它可以容纳"系统 + 一个中等数据库 + 一个 Web 服务"，或者"系统 + 若干轻量容器"，或者"系统 + 一个内存数据集 4G 左右的缓存服务"。对本文讨论的这些场景来说，16G 是"能不能在同一台机器上多干一件事"的分界线。

这里给一条可以直接执行的红线，不管你用的是哪一档：

8G 档：所有常驻进程 RSS 加起来长期超过 6G，就该考虑换机器了。留 2G 给页缓存和突发，是这台机器上比较安全的运行区间。任何一个单进程的常驻内存超过 2G，也要开始警惕。

16G 档：常驻总和长期超过 12G，就该规划迁移。不要把 16G 全部用满，因为数据库、缓存这类服务在快照和重启时都需要额外的内存余量。

两档通用：只要 swap 开始被持续使用，就说明已经越线。这条比任何绝对值都可靠，下一节会展开讲。

还有一个经常被问到的问题：能不能加内存？理论上可以，实际很麻烦。DDR3 的条子在 2026 年的采购市场上越来越少，价格也不见得比当年便宜多少；老主板的内存槽位和单条容量支持都有上限，L5520 这一路官方内存上限在 144GB 量级，但那是要配满大容量条子才有的数字，现实里这批上架的机器多数停在 24GB 到 96GB 这个区间。更关键的是加内存要停机、要开机箱、要机房配合，这个操作成本和它带来的收益往往不成比例。真觉得内存不够，绝大多数情况下换机型比加内存划算。

硬盘那一行怎么读

四档配置里的硬盘写法有三种，这三种写法对应着三种完全不同的数据存放方式，不是随便挑一个就行。

240G SSD（01 档）：系统和热数据全放固态。这种配置适合"数据量不大但每次访问都是随机读"的场景——静态资源源站、小型数据库、装一堆小文件的 Web 服务。240G 扣除系统分区和日志，实际可用大概 180G 到 200G。要注意的是，这一代主板上的 SATA 接口常见规格是 3Gb/s，SSD 的顺序读写通常会被限制在 250MB/s 这个量级，具体取决于实际的主板和磁盘控制器，以上架后的实际表现和机房说明为准。但即便有这个限制，SSD 的随机 IOPS 依然比机械盘高出一到两个数量级，所以系统盘必须是 SSD，这条没有任何商量余地。

180G SSD + 1T HDD（02 档）：最典型的分层结构。这是四档里最实用的组合：系统和数据库放 SSD 上，保证随机读写性能；备份文件、归档日志、历史数据、冷资源放 1T 的机械盘上，只要空间便宜。机械盘的顺序读写速度虽然不高，但备份归档这类活本来就是顺序大块写入，机械盘完全够用。如果你打算在这台机器上做"日备份加归档"，那这 1T HDD 就是为你准备的，别拿它跑数据库。

160G SSD 或 1T HDD（03 档）：这是唯一需要你在下单时做二选一的档位。"或"这个字意味着两者只能选一个，选了就没有另一块。这个选择完全取决于你想让它干什么：要跑系统和服务、要随机读性能、数据总量在 150G 以内，就选 SSD；要放备份、放归档、放一堆不常访问的大文件，就选 1T HDD。选错方向的代价是后面要么忍受 IO 卡顿，要么再掏钱加盘。

160G SSD + 1T HDD（04 档）：两者兼得，且 CPU 和内存也是四档里最高的老平台配置。这一档在本文讨论的所有场景里适应性最广——既有固态跑系统和热数据，又有机械盘放归档，16G 内存允许你多干一件事，20M 独享给了更宽的保底通道。

选盘时还有一个容易被忽略的细节：无论哪种组合，都要提前规划好日志和备份的落盘位置。老机器上最常发生的事故不是硬件坏，是日志把系统盘写满，然后服务跟着挂。把日志目录挂到 HDD 上、配上 logrotate 保留策略、给根分区留足够余量，这三件事应该在机器上架当天做完。

什么时候必须换：三条可执行的判断线

"什么时候该换机器"这个问题，最容易得到的答案是"感觉慢了就换"，这等于没说。下面三条线是可测量、可复现的，任何一条踩穿就该启动迁移，不需要再讨论。

线一：CPU 持续高位，尤其是单核被打满

在双路 16 线程的机器上看 CPU，不能只看总量。16 个线程里有一个跑满 100%，总使用率显示可能只有 6%，但那个跑满的线程对应的任务已经卡死了。所以正确的看法是两层：

第一层看单核。用 top 按 1 展开每个逻辑 CPU 的使用率，或者用 pidstat -u 1 看每个进程的 CPU 占用。如果发现某个进程长期占用接近 100%（单核算下来就是一个核的上限），而它的任务又是无法并行的类型，说明这个任务的单线程耗时已经超过了这台机器能给的水平。这是老平台上最典型的"卡死"形态——不是整体忙，是一个线程在排队。

第二层看整体运行队列。用 vmstat 1 或者 sar -q 看运行队列长度，如果长期高于 CPU 逻辑核数（16），说明已经有任务在排队等 CPU 了。对后台类负载来说，长期 load 超过 12 到 16 这个区间就应该规划迁移；对有响应要求的在线服务，这个阈值还要再低一些。

要注意区分"持续高位"和"凌晨定时任务的短暂峰值"。备份、压缩、统计脚本在夜里跑，把 CPU 打到 100% 是正常现象，只要它能在窗口内跑完、不影响白天的业务，就不算踩线。真正需要换机器的是"白天的常规业务流量下 CPU 就已经高位运行"这种情况。

线二：内存开始用 swap

这条线最干脆，因为它不依赖你的主观判断。用 vmstat 1 看 si 和 so 两列（换入和换出），这两列只要持续出现非零值，就说明系统已经开始把内存里的东西搬到磁盘上。用 free -h 看 swap 的使用量，如果它在业务高峰期稳定增长且不回落，情况就更明确了。

为什么这条线这么严重？因为对数据库和缓存这类服务来说，一旦部分数据被换出到磁盘，它的访问延迟会从纳秒级跳到毫秒级，慢上几个数量级。表现出来的现象是：机器看起来没宕机，CPU 也没跑满，但业务响应突然变得极慢，而且重启服务之后会好一阵子，过段时间又变慢。这种"周期性变慢"是内存不够的经典症状。

还有一类更隐蔽的情况：数据库因为内存不足被迫缩小缓冲池，于是大量查询落到磁盘上，磁盘 IO 跟着飙高，从外面看像是"磁盘性能不行"，实际上是内存不够。排障时先查内存，再查磁盘，顺序别反了。

线三：业务要上新指令集依赖

这条线不需要任何监控数据，它是一个明确的"是或否"。当你要部署的软件在官方文档里写明最低要求包含 AVX 或 AVX2，而这台机器的 /proc/cpuinfo 里没有这些 flag，那这台机器就不在候选范围内，讨论性能没有意义。

常见的触发场景包括：数据库或检索类组件升级到某个大版本之后提高了 CPU 要求；引入了向量检索或轻量推理相关的组件；加密库或运行时升级之后不再提供非 AVX 的构建产物；容器镜像的基础镜像换了新版导致依赖的库要求新指令集。

这条线之所以要单独列出来，是因为它和其他两条的性质不同：CPU 高位和内存 swap 都还可以通过优化代码、调参数、减少负载来缓解，但指令集缺失是硬件层面的事实，唯一的解法是换平台。所以在采购这类老机器之前，就应该先确认自己要跑的东西在未来一两年内不会有这类依赖——如果业务正在往需要新指令集的方向走，那这台机器从一开始就不该进你的清单。

换的时候怎么迁：别想着原地升

确认要换之后，第一个要纠正的念头是"能不能给这台机器加内存、换个 CPU 继续用"。在老平台上，这个念头基本可以放弃。

原因是原地升级的每一步都不划算：换 CPU 意味着换同代的其他型号，而同代型号之间（比如 L5520 换成 X5670 这类）提升有限，花掉的钱和得到的性能不成比例；加内存要买越来越难买到的 DDR3 条子，还要停机开箱；换主板等于换整机，那就不是升级而是重新采购了。更现实的问题是，任何一次硬件改动都要停机，而停机窗口对在线业务来说往往比硬件本身更贵。

所以常规做法就是换机型：选一个新平台的配置，重新上架，把环境搭好，把数据迁过去，然后切流量。这个过程的重点不在"迁"这个动作，而在切换的可回退性。

第一步：新机器上先搭好完整环境。不要边迁边配。操作系统版本、运行时版本、依赖库、配置文件、防火墙规则、定时任务，全部在新机器上先准备到位。这一步要当成一次全新的部署来做，顺便把老机器上那些"不知道什么时候加的"配置项清理一遍。

第二步：数据迁移分两类处理。文件类数据用 rsync 增量同步，先全量同步一次，切换前再做一次增量，这样最终停机窗口可以压到分钟级；数据库类数据要看规模，小规模可以用逻辑导出导入，规模大一点的建议在新机器上配成从库、追平 binlog 之后再提升为主库，这样停机窗口几乎可以忽略。如果数据量太大不便直接同步，可以先落到对象存储做中转。

第三步：提前调低 DNS 的 TTL。如果你是用域名对外提供服务，在切换前一天把 A 记录的 TTL 改到 300 秒甚至更低，这样正式切换时各地解析能比较快地生效。这一步很多人忘了做，结果切换后等了几个小时流量还在往老机器上走。

第四步：灰度切流量并观察。先切一部分流量或者先在内部访问验证，确认服务正常、日志无异常、数据完整之后再全量切。观察周期至少覆盖一个完整的业务高峰。

第五步：老机器不要立刻退。切换完成后，老机器再保留一到两个账期，保持停机但不下架的状态，作为回滚的兜底。这段时间的成本相比于一次失败的迁移，是很便宜的保险。

关于 IP 和备案，有两件事要提前弄清楚。一是 IP：换机型通常意味着换机器，IP 一般不跟着走，新机器会有新的 IP，所以所有硬编码了 IP 的地方——配置文件、监控项、防火墙白名单、第三方平台的回调地址、客户端配置——都要提前列清单改掉。这也是为什么能用域名就别用 IP 的原因。二是备案：备案是按主体和域名做的，但域名解析指向的接入商发生变化时，需要在接入侧做相应的备案接入或变更手续。一万网络官网明示提供免费备案协助（具体流程、所需材料和审核时限以管局要求与官网说明为准），换机之前先跟机房确认这一步的处理方式，不要等切完了才发现解析被拦。

一万网络的角色：把它当存量节点来用

深耕 IDC 19 年（成立于 2007 年）的一万网络，在郑州这一组老机型上承担的角色不是"卖便宜机器的商家"，而是一个存量节点的提供方。这句话的含义有两层。

第一层是机房条件。郑州机房是 T3+ 级别，BGP 线路，带宽充足，稳定性和防护能力（稳定性 99.9%，全方位防御）由机房层面保证，与上面跑的是什么年代的 CPU 无关。这一点很重要——老机器最让人不放心的本来应该是"放在什么环境里"，而这批机器所在的环境本身并不打折：电力、制冷、网络、物理安全、防御能力，都是机房统一提供的，不因为这台机器是 L5520 就降一档。

第二层是长期可续性。一台机器如果你打算让它安安静静待三年，那"三年后这个型号还在不在、还能不能按原价续"就是一个实打实的问题。已经在架上跑了多年、机位和备件都稳定的存量机型，在这一点上反而比新机型更可预期。一万网络这类老机型长期挂在架、可续费的状态，正好对应了"我不需要它变强，我需要它别变"这类需求。

换句话说，如果你要的是算力，这批机器不该出现在你的清单里；如果你要的是"一台放在 T3+ 机房里、有固定带宽、能一直续下去的独占物理机"，那 L5520 和 E5640 在 2026 年依然是一个成立的选择——前提是你清楚自己要往上放什么。

关于这批老机型，采购时最常被问的七个问题

一、L5520 双路加起来到底多少核，2026 年还够用吗

两颗 L5520 加起来是 8 核 16 线程，不是 16 核——每颗是四核八线程，两颗相乘等于八核。E5640 双路同样是 8 核 16 线程，区别在基础频率（2.26GHz 对 2.66GHz）、三级缓存（8MB 对 12MB）和有没有 AES-NI。所以"双路"买到的主要是内存通道数、PCIe 与 IO 能力和整体吞吐，不是核心数的翻倍，这一点在看配置时要先摆正。

够不够用取决于干什么。跑跳板机、备份归档、监控采集、静态源站，8 核 16 线程是明显的富余，因为这些负载 CPU 长期在个位数；跑数据库主库、编译构建、转码，8 核 16 线程不够，而且不是"核少"的问题，是每一颗核太慢的问题。别拿核心数去跟今天的 CPU 比，那不是一个口径。

二、8G 内存在 2026 年装得下什么系统和服务

装得下"一套主流 Linux 服务器发行版 + 一个主服务"。系统本身（含 sshd、日志、cron、监控 agent）常驻 500MB 到 1.5G；剩下 6G 多的可支配空间，能放一个 Nginx 加 PHP-FPM 的中小站点，或者一个堆给到 2G 的 Java 应用，或者一个缓冲池 2G 左右的中小数据库。三样一起来，8G 就紧了。

一个容易翻车的点是 Redis 这类内存数据库：数据集 2G 的话，做 RDB 快照时 fork 出来的进程在写时复制机制下还要额外吃内存，所以实际占用往往要比数据集本身留出一半以上的余量。8G 机器上跑 Redis，数据集最好控制在 2G 以内。

三、DDR3 平台的内存上限大概是多少，想加到 32G 现实吗

从公开规格看，L5520 单路内存上限在 144GB 量级，E5640 在 288GB 量级，但那是要配满大容量内存条才有的理论数字。现实里这批上架的老机器多数停在 24GB 到 96GB 这个区间，上限取决于主板上的内存槽数量、单槽支持的最大容量，以及机房手上还能拿到什么规格的 DDR3 条子。

加到 32G 在技术上通常可行，在经济上往往不划算：DDR3 条子在 2026 年越来越难买，价格也不见得便宜，加上停机、开箱、机房人工这一串成本，算下来很可能不如直接换一台 16G 或 32G 的新平台机型。本文的建议是——内存不够就换机型，别在老平台上加内存。

四、100M 共享和那 10M 独享是怎么同时存在的，机器上到底走哪条

这两条不是二选一，是同时挂在机器上的。10M 独享是保底通道，无论机房里其他机器怎么跑，这 10M 是你的；100M 共享是叠加在上面的突发余量，白天机房整体不忙的时候你能跑得更快，忙的时候会回落到接近保底的水平。

对本文讨论的这些后台负载来说，真正有价值的是那个"保底"。备份同步、监控上报、内网工具访问，需要的不是峰值带宽，是每天那个固定窗口里能稳定拿到一个确定的速率，不会因为邻居跑大流量而中断。至于具体的带宽调度策略和实现方式，以机房的实际配置和官网说明为准。

五、十几年的老机器，故障率是不是比新机器高

要分两类看。CPU、内存、主板这类半导体器件，只要正常运行在机房的温湿度环境里，老化并不明显，反而是"早期失效"期早就过了，剩下的多数是随机故障，跟机器年龄的关系没有想象中大。真正随年龄上升风险的是机械部件和损耗件：机械硬盘的磁头和电机、散热风扇的轴承、电源的电解电容，这些是有寿命的。

所以务实的做法不是"老机器一定会坏"，而是"老机器坏了要有预案"：数据要有异地副本，不要在单台老机器上放唯一一份；监控要盯住磁盘 SMART 值和风扇转速；关键业务不要只挂一台。机器本身所在机房的电力、制冷、网络和防御是统一的，与机器上跑的是哪一年的 CPU 无关。

六、能不能先租一个月试试，不行再换

这是老平台上最适合的做法，也是低月付带来的实际好处：试错成本极低。建议的试法是带着真实负载去试，而不是空跑——把你准备放上去的服务完整部署一遍，把真实数据量灌进去，跑满一个完整周期（要覆盖一次业务高峰、一次夜间备份窗口），然后看三个数字：单核有没有被打满、swap 有没有被使用、磁盘剩余空间下降的速度。

一周到两周基本能得出结论。如果这三个数字都健康，那就长期用；如果任何一个踩线，直接换机型，别在老机器上做优化来硬凑——优化能救的是配置不合理，救不了硬件代际。

七、换机器的时候，备案和 IP 怎么处置

IP 这一项要提前列清单。换机型通常是换机器，IP 一般不跟着走，新机器会用新 IP，所以所有写死 IP 的地方都要改：配置文件、监控项与告警规则、防火墙白名单、第三方平台的回调地址与接口授权、客户端或 App 里的服务端地址。这也是为什么说能用域名就别用 IP——域名只需要改一次解析。

备案这一项要提前跟机房确认。备案是按主体和域名做的，但域名解析指向发生变化时，接入侧需要做相应的备案接入或变更手续；一万网络官网明示提供免费备案协助，具体流程、所需材料和审核时限以管局要求与官网当前说明为准。换机之前先把这一步的流程问清楚，不要等切完流量才发现解析被拦。

老机器该不该留，看这三条线

回到最开始那个问题：十六年前的 CPU 今天还在报价单上，它剩的是什么？答案是物理机独占、固定带宽、低门槛月付这三件与 CPU 型号无关的东西。而它该不该留，不看它有多老，看你有没有踩穿下面这三条线。

CPU 线：白天的常规业务流量下，单核被打满或者运行队列长期超过 16，说明这台机器的算力已经被你的业务吃穿了。内网工具、备份归档、监控采集这类负载不会碰这条线；数据库主库、编译构建、转码这类负载一上来就会碰。

内存线：8G 档常驻总和超过 6G、16G 档超过 12G，或者 vmstat 里的 si/so 开始持续非零，就该规划迁移。这条线对本文推荐的所有场景都适用——跳板机、备份节点、监控采集端都不该碰到它，碰到了说明你在上面堆了不该堆的东西。

指令集线：你要部署的东西要求 AVX、AVX2 或 FMA，而 /proc/cpuinfo 里没有这些 flag，那就不用讨论了，直接换平台。这条线也解释了为什么采购前要先确认业务方向——如果业务正在往向量检索、轻量推理这类方向走，那这台机器从一开始就不该进清单。

把这三条线对应到郑州这四档上（官网明示价，以官网实时价为准）：550 元的 03 档适合放一台纯后台的机器，能选 1T HDD 就选它做归档；750 元的 04 档是老平台里适应性最广的一档，16G 内存加双盘加 20M 保底，能多干一件事；800 元的 01 档和 900 元的 02 档卖点多在机房线路与硬件规格上，选它们之前先确认你吃的到底是不是那份多线接入。至于要不要从 8G 升到 16G，别看 CPU 型号，看你打算在这台机器上跑几件事。

一句话收尾：老平台的剩余价值不在算力，判断要不要换也不是看 CPU 型号老不老——看你的负载吃的是单核性能、内存带宽，还是只要一台长期在线、带宽稳定的独立机器。前面两者碰了就换，后者就让它继续待着。

配置与机房信息以哪份清单为准

本文引用的四档配置与价格，均来自一万网络官网郑州机房页面的明示信息：01 档郑州多线机房服务器（L5520*2 / 8G / 240G SSD / 100M 共享 / 1 个 IP）￥800 元/月；02 档郑州联通中原（E5640*2 / 16G / 180G SSD + 1T HDD / 100M 共享 / 1 个 IP）￥900 元/月；03 档郑州联通中原服务器（L5520*2 / 8G / 160G SSD 或 1T HDD / 10M 独享 + 100M 共享 / 1 个 IP）￥550 元/月；04 档（E5640*2 / 16G / 160G SSD + 1T HDD / 20M 独享 + 100M 共享 / 1 个 IP）￥750 元/月。

需要强调三点：第一，以上价格与配置均以官网实时价与实时清单为准，机房会调整在售机型、带宽组合与价格，下单前请以官网当前页面为准，未明示的规格一律按"需实时询价"处理。第二，本文关于 L5520、E5640 的代际、核心数、缓存、内存规格、指令集等信息，来自该型号的公开规格资料，具体到手机器的实际配置以机房交付为准；文中涉及的内存带宽为按通道数与频率换算的理论值，实际可用带宽低于该值。第三，文中出现的部署思路、负载判断与迁移步骤均为典型场景下的通用技术参考，并非特指某一真实客户，也不构成对具体业务的性能承诺。

CPU 特性是否缺失、内存是否够用、磁盘该如何分层，这三件事最终都有一台机器就能验证的办法：上架之后跑一遍 lscpu、free -h、vmstat 1，再把自己的业务放上去观察一周。老机器值不值，数据说了算。