很多运维排查生产环境 CPU 飙升时，第一反应是业务代码里有死循环或者 SQL 没加索引。但很多时候，把全局日志级别从 DEBUG 调成 WARN，整台服务器的高负载警报瞬间就解除了。
这不是玄学，而是 Linux 内核系统调用在微观层面造成的性能灾难。
当你的程序在高并发下每秒打印数万条 DEBUG 日志时，每一次 log 语句底层都在触发 write() 系统调用。
CPU 必须在用户态（User Space）和内核态（Kernel Space）之间进行昂贵的上下文切换，保存寄存器状态，把数据拷贝进内核的 Page Cache。
当脏页累积到一定阈值，内核后台线程必须强行把缓存刷入 NVMe 硬盘，造成严重的 I/O Wait 阻塞。
如果你的日志框架没有开启完全异步缓冲，主业务线程就会被同步锁或者文件句柄竞争硬生生卡住。
花几万块升级的大厂高配算力，全在给硬盘写毫无意义的废话字符串。
https://x.com/fishjar/status/2117807495142129710?a=10RyUtn7LB6MiEibVLE&s=35
这不是玄学，而是 Linux 内核系统调用在微观层面造成的性能灾难。
当你的程序在高并发下每秒打印数万条 DEBUG 日志时，每一次 log 语句底层都在触发 write() 系统调用。
CPU 必须在用户态（User Space）和内核态（Kernel Space）之间进行昂贵的上下文切换，保存寄存器状态，把数据拷贝进内核的 Page Cache。
当脏页累积到一定阈值，内核后台线程必须强行把缓存刷入 NVMe 硬盘，造成严重的 I/O Wait 阻塞。
如果你的日志框架没有开启完全异步缓冲，主业务线程就会被同步锁或者文件句柄竞争硬生生卡住。
花几万块升级的大厂高配算力，全在给硬盘写毫无意义的废话字符串。
https://x.com/fishjar/status/2117807495142129710?a=10RyUtn7LB6MiEibVLE&s=35
Comments
Be the first to add a comment
Log in to comment