一、先看现场：CDN清洗正常，源站PHP-FPM却“假死” 某客户高防CDN节点回源量只有 3Gbps，源站是 16C32G 的 PHP 业务，PHP-FPM 进程数肉眼可见打满，Nginx 大量 502/504。登录源站一看： ss -s # TCP: 12034 (estab 312, closed 11520, orphaned ...

云主机的安全加固清单大家都背得出来：SSH 换端口禁 root、fail2ban、SELinux enforcing、一堆 sysctl。但裸金属物理机在操作系统下面还压着三层东西——BMC 固件、UEFI/引导链、PCIe DMA 路径。这三层在云主机上是厂商的责任边界，在裸金属上全是你的，而且出厂默认基本都是敞开状态。 我们拿一台双路 32...

一、先说结论：瓶颈不在网卡，在 Nginx 的文件发送链路 一台 10G 单口的机器，NVMe RAID0，nginx 1.24.0，跑静态大文件分发（游戏更新包 + 镜像站）。压测 100 并发拉一个 8GB 的包， ifstat 稳定在 3.8Gbps ，上不去了。 先看进程状态，这里有个反直觉的现象： # mpstat ...

故障现场：10G口服务器，内网穿透下载只有50MB/s 客户环境：轻云互联的大带宽服务器（10G口，公网IP 203.0.113.10），内网有一台NAS（192.168.1.100），需要通过公网访问NAS上的文件服务。最初用最朴素的SSH反向隧道： # 在内网NAS上执行 ssh -R 0.0.0.0:18080:localhost:8...

上周帮一个客户做灾备演练，场景很典型：一台 10G 口的大带宽服务器，2.3TB 业务数据，每天凌晨 3 点跑备份脚本，日志里天天写着 backup done, exit 0 ，耗时 6 分 40 秒。结果真要恢复的时候，解包出来一半文件是空洞，另有一批文件大小对但内容是 0。负责人反复强调"我们有备份，而且很快"。 快，恰恰是问题的一部分。...

先把一个反直觉的事实摆在桌上 同一份 800GB 的 MySQL 8.0 数据，同一个源库，同一个目标端，带宽都是 10Gbps 内网： 方案 A： mysqldump --single-transaction --set-gtid-purged=OFF ，管道进 mysql ，全流程 9 小时 12 分。 方案 B： CLON...

现象：带宽空着、CPU 空着，worker 却全满 先说场景。一台 10G 带宽的机器，跑一个 PHP 的 JSON API，响应体平均 400KB~2MB。压测工具从同机房打过来，QPS 能上 3 万；一放到公网，QPS 掉到 200 出头，`max children reached` 拉满，php-fpm 的 active processe...

大带宽服务器本身不骗人，10Gbps 就是 10Gbps。骗人的是配置里那几个看起来像"性能开关"的参数——它们大部分时候要么互相打架，要么被你用错了地方。下面六个坑，全是拿真机跑出来的。 一、sendfile、aio、directio：三个都开，等于三个都没生效 <!-- 新手最爱抄的"性能全家桶" --> location...

先讲个真实场景 客户在群里刷屏： “香港机器挂了吗？我这边 ping 一直 12ms，监控全绿，但 Web 502、SSH 也连不上。” 登录带外 KVM 一看： uptime 是 47， top 里 ksoftirqd/0 100%， ss -s 显示 SYN-RECV 三万条， dmesg 里狂刷 nf_conntrack...

跨洋迁 TB 级数据，只要你敢用 rsync -avz 硬扛 200ms+ RTT 和随机丢包，它就敢在半夜三点断给你看。更恶心的是断了之后没有断点续传，增量校验一轮又一轮，CPU 和带宽全耗在元数据上。如果你源和目标都是 ZFS，别再用 rsync 了，直接用 zfs send/recv 的可恢复流——但 90% 的人不知道 zfs re...