7月9号，一个select查错误日志，直接导致oom
一、该问题的重现步骤是什么？
1. 用户登录调用/blade-auth/oauth/token接口
2.
3.
二、你期待的结果是什么？实际看到的又是什么？
期待登录响应很快，实际需要十多秒才能返回，日志也没有任何报错，看了下服务器内存，cpu都是正常的
三、你正在使用的是什么产品，什么版本？在什么操作系统上？
Bladex联合版，3.1.0.RELEASE,在Linux操作系统
四、请提供详细的错误堆栈信息，这很重要。
之前登录都很快，近期发现用户登录经常超时
使用ApiFox工具进行验证
使用网页端登录，进行验证
五、若有更多详细信息，请在下面提供。
尝试跳过gateway直接调用blade-auth方法，也会出现超时情况
这是线上生产的系统么？用户数量有多少，你在blade-auth，blade-system几个关键的调用方法的地方打断点，看下是哪一步耗时比较长
我用arthas跟踪了下oauth/token方法，发现是TokenGranter的grant方法执行很慢，但不是每次都很慢
是线上系统，只有几十个用户
我上面发你的连接就是 grant 方法内部会调用的主要节点。你多打点日志看看是哪个地方出的问题。然后才能根据具体情况来推断。
您上面列的几个地方都增加了日志，发现并不慢，但是整个方法还是需要10秒钟
那排查的会相对多一点，你按照这些步骤排查看看：
一、git私服下载对应的原版（https://center.javablade.com/blade/BladeX/releases）找到对应版本从附件下载，然后倒入你的用户、部门等数据，其他的业务模块和业务表不用管。然后用原版登陆看看会不会有同样的问题出现
二、git私服下载最新版（4.6.0，jdk17）同样导入对应数据，登陆看下是否有同样问题出现。
这俩处理完毕后把结果告诉我们，然后我们再来看看怎么排查。
已经排查出原因了，我用的是Cloud版本，在登录的时候，增加了登录日志写入，blade-log部署了2个节点，由于其中一个oom，但是nacos上面服务还在，导致的问题，blade-log在什么情况下会出现OOM？
7月9号，一个select查错误日志，直接导致oom
要修改下tool对应的源码，加一个try catch就没问题了，不加在持续报错场景可能会导致oom
看上面的错误号查询全表导致的？很奇怪调用这个LogErrorController.detail方法怎么会查全表？难道logError里面没有参数？
确实是个问题，给他做下校验
@GetMapping("/detail")
public R<LogError> detail(LogError logError) {
QueryWrapper<LogError> queryWrapper = Condition.getQueryWrapper(logError);
return R.data(queryWrapper.isEmptyOfWhere() ? null : errorLogService.getOne(queryWrapper));
}这样试试
扫一扫访问 Blade技术社区 移动端
加载中...
苏公网安备 32041102000998号