-
一次内存缓慢泄漏的排查:每次都 new 一个 OpenAI 客户端,问题出在事件循环上
排查一个服务的内存缓慢泄漏,翻到同事写的一段后台富化逻辑:每次调用都现造一个 AsyncOpenAI 客户端,连接池悄悄堆成了泄漏。想直接缓存客户端复用却发现根本行不通,根子出在事件循环的生命周期上
-
一次数据库雪崩排查记
被拉进事故群的第一句话是"所有接口都在超时"。先止损让数据库缓过来,再回头查为什么一条两天半前就埋下的隐患,会在这个时间点集中爆发——顺着查下去,是一条忘关的分析查询、一个缺索引的热点接口、外加一把分布式锁在错误的时机被释放,三个凑在一起的完整链条。
-
写了个 IDEA 插件,把 GitHub Actions 塞进了 Git 面板
每次为了看一眼 Action 跑没跑成都要切出去开浏览器,干脆自己写一个得了
-
写了个 IDEA 插件,把项目里的 REST 接口都拍平摆在一个面板里
大仓库里接口一多就靠猜,全局搜索还搜不了完整路径,干脆自己写一个
-
一次 SQS 消费者静默退出的排查:问题最后竟然出在日志里
Web 服务和消息生产都正常,唯独消费者处理一次业务异常后悄悄退出,最后发现真正杀死 Task 的不是业务代码,而是一行错误日志
-
重新理解 MySQL 和 PostgreSQL 的事务隔离级别
从 MySQL 切到 PG 踩了个死锁的坑,顺手把隔离级别这块八股文重新捋了一遍
精选文章
联想510smini小主机
自己总结的命名规范希望能给大家参考
为什么电子垃圾往往会有第二春
开源软件
自动缓存方法数据注解