一次意想不到的性能问题排查
最近几天遇到了一个令人头疼的问题：后端 API 接口响应越来越慢，有时甚至会出现假死状态，完全无法响应请求。唯一的临时解决方案是重启后端服务，但过不了多久问题又会重现。
初期症状：
- API 响应时间从几十毫秒逐渐增长到几秒
- 随着服务运行时间增长，性能持续下降
- 最终会进入假死状态，必须重启才能恢复
- 重启后短时间内运行正常，然后重蹈覆辙
排查过程
这种"越跑越慢"的症状让我首先怀疑是内存泄漏或资源未释放。我尝试了多种方向：
1. 优化缓存策略
面对性能问题，第一反应是减少不必要的计算和请求：
后端 Redis 缓存
- 将频繁查询的数据加入 Redis 缓存
- 对热点接口实施缓存层
- 设置合理的缓存过期时间
前端静态资源优化
// 为静态文件添加版本号/随机码，实现持久化缓存
<script src="/app.js?v=a8f3c2d1"></script>
<link href="/style.css?v=b9e4d3f2" rel="stylesheet">
多层缓存控制
- 服务器端：设置了合理的
Cache-Control响应头 - CDN 层：配置静态资源缓存策略，减轻源站压力
- 浏览器端：利用强缓存和协商缓存机制
// 为静态资源添加缓存头
HttpResponse::Ok()
.insert_header(("Cache-Control", "public, max-age=31536000, immutable"))
.insert_header(("ETag", resource_hash))
.body(content)
这些优化确实带来了改善，缓存命中率提高，响应时间减少。但问题依然存在：服务运行一段时间后，即使缓存命中率很高，整体性能还是会持续下降。
2. 检查数据库连接
数据库往往是性能问题的常见瓶颈，我进行了全面检查：
连接池优化
- 检查连接池配置，确认没有连接泄漏
- 调整连接池大小，平衡并发和资源消耗
索引优化
-- 分析慢查询日志，为高频查询字段添加索引
CREATE INDEX idx_user_id ON downloads(user_id);
CREATE INDEX idx_created_at ON favorites(created_at);
CREATE INDEX idx_composite ON user_points(user_id, last_reset_date);
-- 使用 EXPLAIN 分析查询计划
EXPLAIN ANALYZE SELECT * FROM downloads WHERE user_id = ?;查询性能监控
- 监控数据库查询性能，未发现明显慢查询
- 数据库服务器 CPU、内存资源充足
- 连接数在正常范围内
索引优化后，相关查询速度确实提升了 30-50%，但整体性能下降的趋势并没有改变。
3. 分析内存使用
- 观察进程内存占用，增长并不明显
- 排除了明显的内存泄漏问题
4. 查看系统资源
- CPU 使用率正常
- 内存使用正常
- 磁盘 I/O 出现异常高的写入量 ⚠️
这时我意识到，之前的优化都是"治标"，真正的问题可能在其他地方。
真相大白
当我注意到磁盘 I/O 异常时，突然想到了一个被忽视的细节：日志文件。
查看日志目录后发现：
- 单个日志文件在几小时内增长到 几十 MB
- 每次 API 调用都会产生 多条详细日志
- 大量的 INFO 级别日志记录了每个操作的细节
问题根源找到了：过度的日志记录导致了严重的 I/O 瓶颈。
为什么日志会导致性能问题？
- 频繁的磁盘写入：每个请求产生多条日志，高并发下磁盘 I/O 成为瓶颈
- 文件系统开销：日志文件过大后，文件系统的写入性能下降
- 锁竞争：多线程/协程写入同一日志文件可能产生锁竞争
- 缓冲区刷新：大量日志导致频繁的 buffer flush，影响性能
解决方案
临时方案
立即停止日志输出，让服务先稳定运行：
// 临时禁用详细日志
env_logger::Builder::from_default_env()
.filter_level(log::LevelFilter::Error)
.init();
效果立竿见影，API 响应恢复正常。
长期优化计划
- 调整日志级别
- 生产环境使用
WARN或ERROR级别 - 只在关键路径记录必要信息
- 开发环境可保留详细日志
- 生产环境使用
- 实施日志轮转
- 使用
tracing-appender或log4rs实现日志轮转 - 按大小或时间切割日志文件
- 自动压缩和清理历史日志
- 使用
- 结构化日志
- 使用 JSON 格式，方便后续分析
- 减少冗余信息，提高可读性
- 集中式日志管理
- 考虑使用 ELK 或 Loki 等日志系统
- 将日志收集和分析从应用服务器分离
异步日志写入
// 使用异步日志，避免阻塞主线程
use tracing_subscriber::fmt::writer::MakeWriterExt;
let file_appender = tracing_appender::rolling::daily("/var/log", "app.log");
let (non_blocking, _guard) = tracing_appender::non_blocking(file_appender);
优化日志内容
// 之前：记录所有细节
log::info!("用户 {} 请求了资源 {}, 参数: {:?}", user_id, resource, params);
// 优化后：只记录关键信息
log::debug!("用户 {} 访问资源 {}", user_id, resource);
经验总结
教训
- 日志不是免费的：每一行日志都有性能开销
- 生产环境要谨慎：INFO 级别在开发时很好，但生产环境可能是灾难
- 监控要全面：不要只看 CPU 和内存，磁盘 I/O 同样重要
- 从小处着手：有时性能问题的根源可能是最不起眼的地方
最佳实践
- 分级使用：ERROR 用于错误，WARN 用于警告，INFO 谨慎使用，DEBUG/TRACE 仅限开发
- 配置化：日志级别应该可以通过配置文件或环境变量调整
- 定期审查：定期检查日志输出，删除不必要的日志语句
- 性能测试：压力测试时要关注日志对性能的影响
Rust 日志库推荐
tracing：功能强大的结构化日志框架env_logger：简单轻量的日志实现tracing-subscriber：灵活的日志订阅和过滤tracing-appender：支持日志轮转和异步写入
这次经历让我意识到，性能优化不仅仅是算法和架构层面的事情，系统的每个组件都可能成为瓶颈。日志作为调试和监控的重要工具，使用不当反而会拖累系统性能。
在追求可观测性的同时，我们也要平衡性能开销。最好的日志是那些既能提供有价值信息，又不会影响系统性能的日志。
