一、先钉变量：两台靶机，同一份数据 网上抄来的 my.cnf 在云上翻车，八成不是参数写错了，是 你压根不知道脚下这块盘的瓶颈在带宽还是在 IOPS 。云盘的 IOPS 和带宽是两条独立上限，谁先撞上，决定了你该用 fsync 还是 O_DIRECT。 测试环境，两台配置完全一致的云服务器（16C / 64G / MySQL 8.0.36...

先摆结论：容器内存限制和数据库实例规格，是两个不能互相代替的东西 把 MySQL / PostgreSQL 塞进 Docker 做云数据库多租户，最常见的错误设计是： 把 docker run --memory=16g 当成"这个实例是 16G 规格" 。这在 Web 服务上是成立的，在数据库上是灾难性的，因为内核对两类内存的态度完全不同。...

先把结论摆在前面 同一套 PHP-FPM 配置、同一份业务代码、同样的 20000 QPS，直连源站时 nginx worker 单核 usr% 是 55，挂上高防 CDN 之后涨到 78。带宽没变、QPS 没变、慢查询没变，多出来的 CPU 全部烧在三个你平时根本不会去看的地方： nginx ngx_http_realip_m...

一、别急着 docker run —— 默认 bridge 会把你的高防做废 先说一个我们踩过的坑。某次用 nginx:1.27-alpine 起了一个边缘缓存节点， -p 443:443 -p 80:80 打满，QPS 稍微冲上 3 万，后端日志里 $remote_addr 清一色是 172.17.0.1 。 原因不复杂： ...

一、现象：iPXE 那个令人窒息的 040ee119 去年冬天，一个做 AI 训练平台的客户把 500 台裸金属托管在轻云互联的机柜里，走 iPXE + TFTP 全自动装机。第一次冷启动只上了 50 台，一切顺利。第二次一次性把 500 台 BMC 全部 set power on，问题来了—— iPXE 1.21.1+ (g4bd0)...

美国服务器做面向国内用户的站点，大家第一反应是"带宽够不够"，但真正把体验拖垮的往往不是带宽，是 RTT 与协议栈默认值之间的乘法 。同样一台 4 核 8G 的美国机器，裸带宽 1Gbps 打满毫无压力，可实测单连接下载一个 1MB 的 JS，耗时能到 5 秒以上。下面是我在一台洛杉矶节点的美国服务器上，用 Nginx 1.24 和 Apache ...

高防CDN 回源放大 3.7 倍：PHP 站被打穿的真凶是 session 锁 + fastcgi_next_upstream 先说结论：高防CDN 接入后源站 PHP-FPM 被打满，90% 的情况不是 CC 攻击流量穿透了清洗，而是 「一次用户请求被放大成 3~4 次回源请求，同时每次请求的持有时长被 session 文件锁拖长」 。前者放...

先说结论：10G 大带宽服务器上，PHP 接口返回一个 20MB 的 JSON，客户端跨区域拉，单连接吞吐大概率停在 1.1~1.4Gbps 之间，怎么调 Nginx worker 都不动。因为瓶颈根本不在带宽，在 发送缓冲区除以 RTT ，以及 PHP 到内核之间那条每次都按 8KB 切碎的写入路径。 本文用一台 10G 上行、PHP 8.2...

先说结论：对象存储迁移里，"对象数对得上、总大小对得上"是最没用的两个指标。我见过太多团队拿 rclone size 跑出一致的结果就拍胸脯上线，结果三天后业务方找上门——图片全变下载、增量同步又跑了一整夜、月底账单比预期多出四位数。 下面这七条，全是迁移 写入侧 造成的不可逆损失，跟校验算法没关系，属于迁完就晚了。 一、mtime ...

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