Linux vs Windows服务器选型的5大性能陷阱

　　线上报警那一刻，我正把咖啡杯搁在散热口上——杯底一圈水渍刚漫到主板风扇罩边缘。钉钉弹出第七条「CPU持续98%」，前端老张甩来截图：「你们那个接口，从300ms飙到2.4秒，用户刷三次才进得去」。我切到监控面板，看到那台Windows Server的IO等待时间柱状图跟心电图似的往上蹿，而隔壁三台Linux机器的曲线平得像被熨斗压过。我原以为是数据库连错了，结果查了五分钟发现连的压根不是同一个库——运维小陈给这台Windows机器配了本地SQL Server Express，跑着咱的Java服务还兼职当缓存代理。

文章配图，仅供参考

　　第一大陷阱？文件句柄。Windows默认那两三千个句柄，开二十个线程扫日志就见顶。咱的logback写JSON日志，每行带traceId，每次flush都开个FileStream，Windows上这玩意儿比Linux上open()贵三倍不止。我去年5月上线灰度时，压测QPS没跑多高，日志目录里堆了四百多个.log.zip临时文件，全卡在CloseHandle()排队——因为有个老同事写的压缩工具，用了.NET Framework 4.6的ZipArchive，关流不调Dispose，靠GC回收。等它收完，连接池早超时了。我删了三行代码改用System.IO.Compression，问题当场消失。但谁记得住呢？工单系统又弹了条消息，说「客户反馈上传头像卡顿」，我点开看，又是这台Windows机器扛着OSS上传网关。

　　第二是时间戳精度。Linux用clock_gettime(CLOCK_MONOTONIC)，Windows默认GetTickCount64？你信吗？我们一个超时熔断逻辑依赖微秒级时间差，结果在Windows上跑出来的时间跳变是15毫秒一格，像老式挂钟的秒针——咔、咔、咔。开发时本地Mac测得好好的，测试环境CentOS也稳，上线前QA还点了「已验证」，直到灰度第三天，运维半夜打电话问：「为啥同一笔支付，下游收到两个不同timestamp？」我说你查下服务器时间源，他说NTP校准正常啊。后来翻到底层SDK才发现，某个封装HTTP Client的jar包，底层用System.nanoTime()做请求起始计时，而JVM在Windows上居然把nanoTime映射到QueryPerformanceCounter……但服务器BIOS里那个RDTSC指令被虚拟化层拦了一半。我承认这块我没完全搞懂，但我知道删掉那行timestamp打点，改用request header里传的时间，世界立刻清静。窗外天黑了，楼里灯一盏接一盏亮起来，像一排等着被踩爆的雷。

　　第三大坑，TCP backlog队列。Linux默认somaxconn是128，能手动扩；Windows Server的TcpMaxConnects注册表项？改完要重启整个网络栈。我们有个接口被前端疯狂轮询，每秒三十多次，每次带五个长查询参数，Windows那台机器accept queue满了以后，新连接直接被RST，前端重试机制又没退避，雪崩就来了。产品王姐上周拉着我吵了二十分钟：「你们后端能不能把失败响应码统一成503？」我说「可以，但你得先让前端别拿499当200使」——她键盘声很响，敲得我太阳穴突突跳。其实真正该吵的是当初为什么非选Windows：就因为某外包公司说「IIS部署快」。快？快得过ansible一键拉起七台Docker？快得过我们改个配置不用重启整个CLR进程？

　　第四，内存页交换。Linux有swappiness=1，Windows？它管这叫「页面文件自动管理」，然后默默在C盘根目录塞了个64GB的pagefile.sys，还开着压缩功能。我们缓存层有个定时清理线程，扫描LRU链表时Windows会频繁触发页面换入换出——不是因为内存不够，是因为它觉得Java堆里那些老年代对象「看起来不太活跃」。我查top的时候看见RES列数字忽高忽低，差点以为有内存泄漏。结果是Windows自己在后台搞ASLR重映射。我跟运维小陈视频排查，他那边屏幕右下角弹出「Windows更新下载中」，我俩对视三秒，默默关掉了远程桌面。

　　第五，反常识的是线程调度。Linux CFS调度器对短时高频任务友好，Windows的Dispatcher Header优先级模型？在Java线程池固定核心数情况下，反而更容易让IO线程饿死。我们有个WebSocket推送服务，Windows上平均延迟波动±400ms，Linux上基本贴着15ms横线走。我原以为是Netty版本问题，降级到4.1.77再编译一遍，没用。后来发现，只要把Windows服务的启动方式从「本地系统账户」改成「指定域账户」，并且勾掉「以服务方式登录」权限，延迟立刻回落。没人能解释清楚为什么——微软文档写「影响令牌特权」，我们查了整整两天，最后是招聘新来的应届生，用Wireshark抓包时顺手开了ETW跟踪，发现权限变更后，Windows跳过了某个内核驱动的完整性校验路径。手机亮了一下，是猎头发来消息：「听说你们在招底层性能优化的工程师？」我回了个「？」，没点进去。

　　说白了，优胜劣汰这事真不玄乎。不是Linux天生多厉害，是跑过的项目够多，踩过的坑够疼，社区把坑填平的速度比Windows团队修复Server Core里一个SMB签名bug快得多。Linux的烂毛病我熟——比如某些发行版默认禁用透明大页，结果MySQL突然OOM；Windows的烂毛病我也熟——比如PowerShell脚本里写「-eq」和「-ceq」区别大到能让整套自动化发布流程在凌晨三点静默失败。但前者至少能grep源码，后者你得订微软Premier支持，排队排到下季度。我抽屉里还有张去年5月的会议纪要复印件，上面写着「暂定Windows方案，待评估替代路线」，字是我写的，但没人签字。现在它卷着边，夹在《Windows Internals》第七版中间，那本书我只翻了前三章，后面全是灰尘。

　　明天早上我要去查那台Windows机器的Page Fault Delta指标，看是不是真的被WFP（Windows Filtering Platform）钩子拖慢了SSL握手。或者，干脆装个eBPF for Windows预览版试试？算了，还是先看看JVM GC日志里有没有GCLockerInitiatedGC……算了，我先把这杯凉透的咖啡倒了。你听没听见？小陈那边机房空调又嗡嗡响了，八成又是UPS告警，反正今天也修不完。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!