IT运维避坑：服务器慢排查与Core Web Vitals优化实战

做IT运维这几年，最怕的不是系统崩，而是明明在跑、用户却说慢。最近帮恩威信息网做了几次服务器性能排查，发现几个高频坑，今天拆开聊。

坑一：数据库连接池耗尽，页面直接503

现象是网站偶尔打不开，刷新一下又正常。排查时先看了Nginx日志，发现大量upstream timed out。用netstat -an | grep 3306 | wc -l一看，连接数超过300，而MySQL的max_connections才设了200。原因是后台定时任务脚本忘了关闭数据库连接，高峰期堆积。

修复方法：把连接池上限调到500，同时给脚本加mysqli_close()。建议运维定期用SHOW PROCESSLIST检查长连接。

坑二：未压缩的图片拖垮LCP，Core Web Vitals标红

有次恩威信息网销售反馈，客户说产品页面加载太慢。查了Google Search Console，LCP标红到4.2秒。用Chrome DevTools看Network，一张产品原图居然2.8MB。服务器带宽才10Mbps，单图加载就要2秒多。

解决：在Nginx里开启gzip压缩，图片统一用WebP格式，并设置image/png和image/jpeg的缓存头。改完后LCP降到1.8秒。

坑三：DNS解析超时，用户等5秒才看到白屏

这个坑很隐蔽。用户投诉“网站打不开”，但服务器负载正常。用dig www.enweiinfo.com +short测试，发现解析时间波动大，有时超过3秒。原因是使用了免费公共DNS，没有配置缓存。

排查命令：time dig www.enweiinfo.com 看耗时。解决：自建内网DNS缓存（用dnsmasq），或者换用靠谱的付费DNS服务，TTL从60秒提到300秒。

常见坑清单 & FAQ

• 坑4：PHP-FPM进程数太少，高峰期502。检查pm.max_children是否匹配内存。
• 坑5：磁盘I/O瓶颈，慢查询日志写太多。用iostat -x 1看await值。

FAQ：Q：Core Web Vitals怎么快速监测？A：用Lighthouse在本地跑，或Chrome User Experience Report查历史数据。Q：Nginx gzip要特别注意什么？A：确认gzip_types包含text/html application/javascript image/svg+xml，但不要压已压缩的格式如jpg。

复盘总结

这三个坑都有一个共同点：平时监控不够细。建议运维把连接数、LCP、DNS耗时都加到告警规则里，别等用户投诉才查。恩威信息网的经验是，先搞定数据库和图片这两个大头，Core Web Vitals能立竿见影。