看描述是数据库宕机 不是express吧 可以提供下出问题时间observer.log
springboot直接报错无法连接 的具体报错信息也贴一下
看描述是数据库宕机 不是express吧 可以提供下出问题时间observer.log
springboot直接报错无法连接 的具体报错信息也贴一下
麻烦把你的搭建架构和业务sql schema和常见查询,另外32u 52g的配置很奇怪的,你的yaml文件怎么写的,首先sys租户不是用来做业务的,另外你的yaml怎么写的,分配给sys租户多少资源
这里更正下 服务器 D 192.168.1.23 ocp 4.1 64核128G 1.2T SSD
关联同问题
资源和yml我都放在下面了
有core文件生成么
有结果后,辛苦贴子上更新下原因
sys租户不适合当业务使用,可以先考虑新建业务租户,数据导出再导入到业务租户里,应用程序使用新的业务租户连接。
补充一个问题 我把这个 major_freeze_duty_time 合并定时任务执行时间改成了6点 合并就出现访问不了
@AntTech_LTEW4O @tianya
基本确定为同类型问题,可执行文件也发下吧,这边看下用gdb二次验证下。
解决方案:
可以参考原问题中 HaHaJeff 给的方案,
或者是参考用户自身探索的方案,
这边请教一个问题,我这边大量的insert操作能否均衡一下到其他两个zone2 zone3 节点上 感觉现在除了zone1的主节点 其他两个节点在空跑。还有我数据库链接主节点192.168.1.20:2881 和我链接192.168.1.23:2883 有什么区别 后者能够负载吗? 如果他是负载的话那是不是瓶颈就是他 因为我之前没上线的时候做了压力测试 4台 容器每个线程池跑1000 只能开启两台
通过proxy,再加上你配置的primary zone随机打散,会把sql均衡打散到不同的zone上,当然是前提你的表的主分区不能都在同一个节点上
这边的访问不了是指本次问题关联的操作条件么,可以看下对应时间的日志反应
不是 压力测试的时候测的单台连接池1000并发*4台机器 只能开启两台 后来通过测试池只能设置64 *4 这样不会死