Closed MoonBottle closed 5 months ago
TIMED_WAITING 的线程通常没有什么问题。
有没有什么特殊业务,是操作较大量数据的 flatMap
,groupBy
,window
等操作.
有没有什么特殊业务,是操作较大量数据的
flatMap
,groupBy
,window
等操作.
有的,数据导出,历史数据曲线(1分钟一条)之类的需求有用到
设置 并行度试试如: flatMap | groupBy(xxx,Integer.MAX_VALUE)
2.0.0 版本
jstack 信息 1.txt
没有这个逻辑
没有这个逻辑
增加这段逻辑。
2.0.0 版本 jstack 信息 1.txt
看上去并没有线程阻塞。
对比一下master pom.xml 的
reactor.version
2.0.0 版本 jstack 信息 1.txt
看上去并没有线程阻塞。 对比一下master pom.xml 的
reactor.version
2020.0.22
修改为master的版本
因为这个问题触发原因现在是未知的,我先改了观察观察,非常感谢
因为这个问题触发原因现在是未知的,我先改了观察观察,非常感谢
已知的可能性:
Hooks.onOperatorError
捕获并转换为RuntimeException
看着 3 的可能性更大些,但奇怪的是也没有 block 的线程为什么会影响到登录接口超时
看着 3 的可能性更大些,但奇怪的是也没有 block 的线程为什么会影响到登录接口超时
可以尝试调用其他接口,看是否也超时。
version 接口可以调用
下面俩接口超时 api/system/config/amap api/menu/user-own/tree
version 接口可以调用
下面俩接口超时 api/system/config/amap api/menu/user-own/tree
别的接口也试了下,也都是超时的情况
那就更新再试试?
嗯嗯,我先更新上去,观察观察
昨天的改动更新上去之后还是会有假死的情况
触发条件是出现大量的死锁
并且发现在假死的情况下,查询 es 中的设备日志接口能正常调用
昨天的改动更新上去之后还是会有假死的情况
触发条件是出现大量的死锁
并且发现在假死的情况下,查询 es 中的设备日志接口能正常调用
那就是数据库连接池耗尽呗。 检查哪里执行的这个sql操作。
请教下,怎么以非事务的形式执行sql,也就是某些sql我可以不加锁
截图中的 sql 出现的地方挺多的,但奇怪的是之前的正常的,昨天突然不正常了
return pigstyInfoService.createUpdate()
.set(PigstyEntity::getAlarmState, AlarmRecordState.warning)
.where(PigstyEntity::getDeviceId, info.getTargetId())
.execute()
比如这样的sql
执行频率高不高。完整的调用逻辑大概是咋样的。
执行频率很高(设备一直在上报),完整执行逻辑是设备上报各个属性,存储到设备的子属性表后,监听子属性表的 EntityModifyEvent 或者 EntitySavedEvent 再回写到设备主表的一个字段里做冗余
请教下,怎么以非事务的形式执行sql,也就是某些sql我可以不加锁
截图中的 sql 出现的地方挺多的,但奇怪的是之前的正常的,昨天突然不正常了
可能与并发修改相同数据有关。
高频写入,建议使用buffer 批量写入。 可参考 : https://github.com/jetlinks/jetlinks-community/blob/master/jetlinks-manager/device-manager/src/main/java/org/jetlinks/community/device/service/DeviceMessageBusinessHandler.java#L341-L379 。
看了下,这个我改动的地方还挺多,有啥办法可以以非事务的形式执行sql么,我想先改了试试,因为数据一直在上报,能接受非事务执行
高频写入,建议使用buffer 批量写入。 可参考 : https://github.com/jetlinks/jetlinks-community/blob/master/jetlinks-manager/device-manager/src/main/java/org/jetlinks/community/device/service/DeviceMessageBusinessHandler.java#L341-L379 。
看了下,这个我改动的地方还挺多,有啥办法可以以非事务的形式执行sql么,我想先改了试试,因为数据一直在上报,能接受非事务执行
注解@Transactional
或者使用TransactionalOperator
手动管理事务。
/**
* 设备设为告警状态
*/
@EventListener
@Transactional(propagation = Propagation.NOT_SUPPORTED)
public Mono<Integer> triggerAlarm(AlarmHistoryInfo info) {
String targetType = info.getTargetType();
// 设备告警
if (DeviceAlarmTarget.TYPE.equals(targetType)) {
return pigstyInfoService.createUpdate()
.set(PigstyEntity::getAlarmState, AlarmRecordState.warning)
.where(PigstyEntity::getDeviceId, info.getTargetId())
.execute();
}
return Mono.empty();
}
为啥使用了 @Transactional
注解还是会加锁呢
这和事务没关系吧,还有 deviceId
是否加了索引。
deviceId
有加索引
其他地方有没有查询操作。
其他地方有没有查询操作。
有查询 pigstyInfo 的操作
其他地方有没有查询操作。
还挺多的,业务都是围绕这张表做的
改成buffer 修改状态试试吧。 参考设备状态同步那个逻辑。
改成buffer 修改状态试试吧。 参考设备状态同步那个逻辑。
好
解决了,谢谢大佬,是我在设备上报属性的监听里做了太多事,导致长事务了
大佬,不好意思再打扰一下,今天生产环境遇到假死问题了,有几个线程的 cpu 一直很高,导致服务无法登录以及别的操作,重启后恢复正常,麻烦有空了帮忙看一下,不着急
这是相关日志:server.log
jetlinks-core版本是最新1.2.2么。 看一下jstack -l结果
jetlinks-core版本是最新1.2.2么。 看一下jstack -l结果
是最新的 1.2.2 ,已经重启了,下次再遇到我 jstack -l 一下
大佬,今天又遇到了,这是 jstack -l 的日志: jstack.log
有部分设备使用的是 python
的 paho.mqtt
库,调用了 loop_start()
然后观察日志发现很多日志 log.info("device [{}] session [{}] changed to [{}]", old.getDeviceId(), old, newSession);
debug 了下,发现也会走到 jstack 日志里面的 AbstractDeviceSessionManager.java:592
,不知道是不是这个影响了
一个设备会重复创建mqtt连接?
一个设备只允许一个连接,如果有多个连接,会断掉之前的连接。
一个设备会重复创建mqtt连接?
早上研究了下,生产环境应该不是这个原因,没有相关的这些重复连接的日志
jstack-0412.log jstack-041202.log jstack-041203.log jstack-041204.log jstack-041205.log
大佬,昨晚又出现了,我 jstack -l 了上面这些日志,有空的话,麻烦帮忙分析下? 感谢!
cpu 内存占用高么? 看上去是在接受消息后应答是有死锁?
是最新的代码么 ,对比一下这里。
CPU 占满了,我来对比下代码
现象:系统登录接口超时
排查过程: 系统出现很多 TIMED_WAITING 状态的线程
初步怀疑是数据库出问题,然后发现 pgsql 确实有死锁,全部终止后,系统还是没恢复正常(登录超时)
依然有很多 TIMED_WAITING 状态的线程