## 背景 近期一个大版本上线后，Python编写的api主服务使用内存有较明显上升，服务重启后数小时就会触发机器的90%内存占用告警，分析后发现了本地cache不当使用导致的一个内存泄露问题，这里记录一下分析过程。 ## 问题分析 ### LocalCache实现分析 该cache大概实现代码如下
本文详细的记录了一次0点接口严重超时的问题排查经历。本文以作者自身视角极具代入感的描绘了从问题定位到具体的问题排查过程，并通过根因分析并最终解决问题。整个过程需要清晰的问题排查思路和丰富的问题处理经验，也离不开公司强大的调用链、和全方位的系统监控等基础设施。
使用场景： 由于表数据量巨大，导致一些统计相关的sql执行非常慢，使用户有非常不好的体验，并且sql和数据库已经没有优化空间了。(并且该统计信息数据实时性要求不高的前提下) 解决方案： 整体思路：创建预处理表——通过定时任务将数据插入到结果表——统计信息时直接通过结果表进行查询——大大提高响应速度
为了保证系统稳定性，预防潜在慢SQL导致应急事故，发起慢SQL常态化备战专项，下文主要描述专项的实践及落地情况。
在DBS-集群列表-更多-连接查询-死锁中，看到9月22日有数据库死锁日志，后排查发现是因为mysql的优化-index merge（索引合并）导致数据库死锁。
本文记录了一次排查FullGC导致的TP99过高过程,介绍了一些排查时思路,线索以及工具的使用,希望能够帮助一些新手在排查问题没有很好的思路时,提供一些思路,让小白也能轻松解决FullGC问题
前言 从几年前第一个硬盘故障导致参赛的文件丢失之后，我就开始意识到数据安全的重要性，开始用各种云盘做备份，当时还不是百度云一家独大，我们也都没意识到网盘备份是极其不靠谱的行为，直到因为某些不可抗力因素，一夜之间所有网盘都宣布停服，这时才意识到，数据始终是掌握在自己手中才安全可控。 随着数据量增大，我
原因 当Windows操作系统遇到严重错误导致系统崩溃时，屏幕显示为蓝色，通常伴有错误代码和信息，这被称为“蓝屏死机”（Blue Screen of Death，简称BSOD） https://www.thepaper.cn/newsDetail_forward_28126297 这次蓝屏事件影响非
Apache Doris 2.3 以下的版本会存在一个 bug，导致数据在合并时存在异常，在后续查询该字段数据时会提示 [1105] [HY000]: errCode = 2, detailMessage = (192.168.15.228)[CANCELLED]failed to initiali
之前帮客户处理了一个因证书过期导致 vCenter Server 无法登录的问题，在此记录一下，因为时间过去有点久了，可能会有些地方描述的不是很清楚，所以就当作参考就行。客户环境是一个非常老的 vCenter Server 5.5 版本并基于 Linux 版本的 VCSA （当时这个版本还有基于 W
日常Bug排查-MVCC和for update混用导致读数据不一致 前言 日常Bug排查系列都是一些简单Bug的排查。笔者将在这里介绍一些排查Bug的简单技巧，同时顺便积累素材。 Bug现场 又是喜闻乐见的读数据不一致的问题。这次的问题是这样，业务在一个事务中更新A和B两个表的两个数据。但是在另一个
现象 首先有一个被服务由于内存有限，导致巨卡。导致调用他的服务出现线程阻塞。jstack打印线程池如下所示： 开始排查解决问题 第一步：检查代码看是否超时设置是否正确，因为感觉超时设置正确不可能阻塞。 找到注入client的位置： 发现配置没有任何问题，此时感到了一点点慌张。（内心OS： 难不成Ht
1.问题 微信开放社区链接 尝试过新版canvas,在企业微信中签名依然是依然断触,有问题的手机是iphoe15,系统版本以及企微版本微信版本均与签名正常的手机一致,但是那个手机就是无法正常签字,在微信中无论新旧canvas均能正常签字 2.解决方案 既然canvas的touchmove触发有问题,
.NET 7的发布，升级VisualStudio 2022的17.4 版本，然后无法打开所有解决方案。提示信息如下异常：SDK解析程序失败:"尝试解析SDK"Microsoft.NET.Sdk"时，SDK解析程序”Microsoft.DotNet.MSBuildSdkResolver“失败。异常：*
这一次重启真的无法解决问题了：一次 MySQL 主动关闭，导致服务出现大量 CLOSE_WAIT 的全流程排查过程。 近日遇到一个线上服务 socket 资源被不断打满的情况。通过各种工具分析线上问题,定位到问题代码。这里对该问题发现、修复过程进行一下复盘总结。 先看两张图。一张图是服务正常时监控到
背景：linux环境下，服务器由于某种异常导致rsyslog message不停打印到console控制台，影响我们正常使用。 ps：我遇见的场景： 解决办法：1. vim /etc/rsyslog.conf 2.找到“# Everybody gets emergency messages”后注释掉
https://juejin.cn/post/6854573220733911048 遇到了一个 glibc 导致的内存回收问题，查找原因和实验的的过程是比较有意思的，主要会涉及到下面这些： Linux 中典型的大量 64M 内存区域问题 glibc 的内存分配器 ptmalloc2 的底层原理 如
背景 前段时间我们将 istio 版本升级到 1.12 后导致现有的应用监控有部分数据丢失（页面上显示不出来）。 一个是应用基础信息丢失。 再一个是应用 JVM 数据丢失。 接口维度的监控数据丢失。 修复 基础信息 首先是第一个基础信息丢失的问题，页面上其实显示的是我们的一个聚合指标istio_re
遇到的问题 因为新增了一个控制器方法，从而导致在运行Swagger的时候直接报错，异常如下： SwaggerGeneratorException: Conflicting method/path combination "POST api/UserOperationExample" for acti
