V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  summer7  ›  全部回复第 2 页 / 共 2 页
回复总数  32
1  2  
@yidinghe 感谢回复。
1、确认后没有内存泄漏,一次 FullGC 之后内存基本和刚启动时一样.但是一次 10 并发,基本就要 Full GC 一次,楼下也有大佬提出修改 young 和 old,我试一下看看,将 young 设置大一点。
2、对于取一条数据解析一条,嗯。。其实一直有个疑惑,while(resultSet.next ())的时候,这个 resultSet.next 是不是就相当于一个游标,其实数据还是存在于数据库端的?还是说不同数据库有不同的实现方式?
@sadfQED2 感谢回复。数据要求实时查询。加机器配置这个事情,难呀。
@bobuick 目前我单纯的本地写个 for 循环去触发查询接口,基本上每调用 9 次就会触发一次 Full GC,之后内存迅速下降,基本等于刚启动时候的内存。 改改参数看吧,也是第一次遇到这种问题
@BBCCBB 感谢回复。G1 会尝试一下的。
@l8g 感谢回复。楼上也有大佬提到修改 young 和 old,我会试一下的。 说起来,拆分查询也是一个头疼的事情,目前底层存储库不支持这种比如 limit 这种拆分查询
@babyvox5th 数据 JDBC 查询完,就是内存操作了目前。
@bobuick 感谢回复。young 设置大一点我会验证试一下的。这是第一次遇到这种 GC 问题,不知像互联网那些高并发项目,Full GC 频率的合理范围是多少呢?还请指教
@ipwx 嗯,以前 hbase 做存储时已经是结构化的数据了,但是后来换了数据库必须要调用方去解析这些数据。其实整体数据流程很简单,jdbc 查询,查完解析入库。
@jimrok 补充:是单次请求解析需 2-4s
@jimrok 数据流程大概是这样,第一步 jdbc 查库,第二步:对每条数据做解析,第三步:入 redis。 目前问题主要集中在解析这个过程 32 核机器跑满也需要 2-4s,稍微来个并发(不到 10 个),10g 的堆因为 gc 导致解析时间会上升到 20s+
@chendy 需求大概是这样的:从数据库查出 30000 条数据,数据部分字段会包含长文本,单条数据约 200+字段,查出后需要对数据解析,据观察内存涨幅约等于 900m
@lihongjie0209 是的,这个项目基本等于没有并发。 10 并发也到不了。
1  2  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   892 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 14ms · UTC 22:30 · PVG 06:30 · LAX 14:30 · JFK 17:30
Developed with CodeLauncher
♥ Do have faith in what you're doing.