"/data/jsq20230228//esProc/bin/ServerConsole.sh -p 启动集算器进程；启动参数内存大小为 -Xms30G -Xmx30G 应用使用 jdbc 连接 .."
/data/jsq20230228//esProc/bin/ServerConsole.sh -p启动集算器进程；启动参数内存大小为 -Xms30G -Xmx30G应用使用 jdbc 连接；执行 20 个左右请求后 前端连接超时，超时时间为 30 秒，集算器未报错，进程正常；
运行一段时间后连续访问性能严重下降。
这个问题上个月修正过，你使用的版本是最新的吗
是最新的，esproc-bin-20230228.jar 包是李松波李总发我的； 这次我是用的组表，不知道有没有区别；
Statement、Connection 有及时 close 么
不对，你这可能是 2 月的包，修正 statement 和 connection 关闭后内存不释放是 3 月才做的
Statement、Connection 都有 close
包是李松波李总单独发我的啊，应该是他手动打的包吧；
更新了昨晚发布的 jar 包后，感觉好了点，但是还是有一些问题，2 个用户并发 10 笔交易； 有几笔交易是超时的，超过了 30s
1、频繁 gc 说明内存不足，此时再连出现超时很正常2、这要找出内存为什么不足，可能是一个脚本执行过程中占用内存太多了，也可能是多个脚本并发时共同消耗太多内存，这个得具体问题具体分析
使用企业版集算器，有个 Monitor 监控端，使用它可以实时看到在节点机上正在计算的作业，通过监控还可以取消执行当前作业。另外可以自己估算一下单个作业大概占用的内存以及计算完成的耗时。从而判断能支持多大的并发量
自动连接惹的祸，没有自动释放不注意的话，这玩意可能让每个脚本的数据库连接 +1
自动连接惹的祸，没有自动释放不注意的话，这玩意可能让每个脚本的数据库连接 +1可以更新 jar 了
这个问题上个月修正过，你使用的版本是最新的吗
是最新的，esproc-bin-20230228.jar 包是李松波李总发我的； 这次我是用的组表，不知道有没有区别；
Statement、Connection 有及时 close 么
不对，你这可能是 2 月的包，修正 statement 和 connection 关闭后内存不释放是 3 月才做的
Statement、Connection 都有 close
包是李松波李总单独发我的啊，应该是他手动打的包吧；
更新了昨晚发布的 jar 包后，感觉好了点，但是还是有一些问题，2 个用户并发 10 笔交易； 有几笔交易是超时的，超过了 30s
1、频繁 gc 说明内存不足，此时再连出现超时很正常
2、这要找出内存为什么不足，可能是一个脚本执行过程中占用内存太多了，也可能是多个脚本并发时共同消耗太多内存，这个得具体问题具体分析
使用企业版集算器，有个 Monitor 监控端，使用它可以实时看到在节点机上正在计算的作业，通过监控还可以取消执行当前作业。另外可以自己估算一下单个作业大概占用的内存以及计算完成的耗时。从而判断能支持多大的并发量
自动连接惹的祸，没有自动释放
不注意的话，这玩意可能让每个脚本的数据库连接 +1
自动连接惹的祸，没有自动释放
不注意的话，这玩意可能让每个脚本的数据库连接 +1
可以更新 jar 了