雪落南城的博客

线上fullgc

背景线上数据库偶发出现慢查询，导致业务处理时间变长，由于上游重试机制不完善，导致了业务流程错误原因表象上看，某台数据库cpu使用率升高并且使用了swap内存根因：问题思考1.数据库稳定性问题2.业务重试机制需要完善，立即重试 + 延时梯度重试...

背景原因

背景：业务A的数据库某个实例异常，操作下线后再上线，业务A线程被打满无法处理新请求

线上发生了一次退款失败的case，通过客诉反馈，这个问题出现的几率极低，跟了半天日志，发现了根因：上游重复调用了两次，这两次调用打在了不同的机器上；而且先打到的机器并没有原子性的执行完步骤一和步骤二，导致机器B处理时步骤一的逻辑处理是错误的，同时导致步骤二结果不符合预期；机器A执行步骤二时，由于机器B已经执行并落库，因数据库唯一索引导致机器A执行失败；执行顺序大致是这样的解决1、代码增加分布式锁 防止并发问题2、代码逻辑优化，保证幂等性，分布式锁解决不了间隔时间较长的重复调用。...

首先我想说，牛逼。背景由于一个服务迁移到了我们组，线上报了一个swap.used.percent = 100，然后观察gc日志发现了一个young gc时间达到12s的case冷静分析这个服务所在的机器配置是4c8g，讲道理，如果用到了swap，说明机器内存不足啊！看了一下这个服务的堆内存大小是12G！就，牛逼。解决方案1.升级机器2.修改堆大小...

今天在开发的过程中，遇到了一个问题，原因是父类重写了toString方法，但是子类用了@Data注解 导致父类的重写方法没有继承过程解析：1、父类：子类：可以看到继承了父类 但是没有重写toString方法子类编译的文件：是lombok实现的toString方法导致 子类在使用toString方法时 并没有按照预期转成JSON格式...

事件4.13号测试部署的服务突然爆oom异常第一次OOM异常如下：2020-04-14 14:42:43.092 - - [ERROR] Druid-ConnectionPool-Create-755299134 DruidDataSource (DruidDataSource.java:2699) create connection SQLException, url: jdbc:my...

1、ps -aux ,若STAT那一栏为Z，则说明是僵尸线程2、ps -ef |grep 僵尸进程ID，即可以找到父进程IDkill掉父进程即可

1、top -c 列出进程相关信息，按大写P按照CPU使用率排序2、找到进程后，定位耗费CPU的线程 top -Hp pid3、定位哪段代码导致的CPU过高1、先把定位到的线程ID转换为16进制printf "%x\n" 线程ID2、jstack 进程ID | grep ‘16进制的线程ID’ -C5 --color jstack 9029 | grep '236e' -C5 -...

1、原SQL使用了datediff(now(), pu.should_repay_time) in (1,3,5,7)should_repay_time本来有索引的，但是使用了函数之后索引会失效查了好几秒 不能忍受的速度2、为了使should_repay_time的索引生效，不对其使用函数，将sql改为pu.should_repay_time in (DATE_FORM...

由于日志输出问题，导致磁盘迅速张满1.df -lh查看磁盘空间2、du -h --max-depth=1定位占磁盘最大的文件夹3、ls -lhs按照文件大小排序展示文件4、查询该文件的引用 lsof 文件名5、kill -9 引用的进程6、rm -rf 文件名删除大文件...