07:38:37 csp
07:38:58 csp
头条赞赏还是微信支付宝
07:40:02 csp
是通过头条中转微信和支付宝？
08:14:02 北京一张泽雄
人工也能做成自动的，用自动化角本，参考下autoIT.
10:04:40 忘忧草
10:05:00 忘忧草
有人遇到过没，偶现gc超长，大概一个月左右才出现一次
10:09:00 donson
用g1[呲牙]
10:09:55 忘忧草
之前是用的g1，也出现过一次19s，现在换成cms还是偶现
10:11:07 窦巍
先想办法复现
10:11:55 窦巍
一个月复现一次无从下手。在load test 阶段想办法复现
10:12:48 忘忧草
平时单机qps在400左右，峰值也就600多，出问题的时候并非峰值
10:14:26 so what
看下这个时间段的机器io
10:14:35 so what
是否swap
10:14:47 窦巍
看看old generation 因为什么增长吧。改g1或cms只是调优不解决根源的
10:14:54 忘忧草
10:15:06 忘忧草
当时io是挺高，但是swap并没有打开
10:15:11 忘忧草
我们默认都是关闭的
10:15:24 窦巍
是促发了full gc么？
10:15:47 so what
io会影响gc时间的
10:16:05 so what
再对照下上次长gc 看看是不是也是io的问题
10:16:58 忘忧草
gc理论上都是内存操作，io影响的原因是？
10:17:06 忘忧草
在无swap的前提下
10:20:51 so what
gc时间包括gc的处理时间 + 写gc日志的时间
10:21:27 so what
https://www.cnblogs.com/rainy-shurun/p/5830455.html
10:22:35 忘忧草
[强][抱拳]
10:23:08 donson
看了你的GC，耗时很长的那次gc和之前的gc和之后的gc收集的空间大小几乎一致
10:23:43 donson
所以不是因为收集大量的垃圾导致的gc时间长
10:23:58 忘忧草
是的
10:24:15 donson
gc耗时长的那次正好发生了大量的IO
10:24:19 忘忧草
从jvm本身解释不通
10:25:39 donson
可以把gc写日志 关闭
10:26:38 bill在飞
不是提示 allocation failure吗？
10:26:54 bill在飞
这个什么原因？
10:27:25 so what
1.7都有这个
10:28:07 donson
@刘华伟-陌陌-开发 赞
10:29:19 bill在飞
原来这是gc的cause
10:29:31 张起坤
这说明有东西回收不掉
10:31:44 张起坤
之前我们出现过，每大约两个星期就会内存回收不掉，导致应用几个小时都不能处理交易，直到应用自动重启或者手动重启就好了
10:33:21 donson
是什么回收不掉，内存泄露了还是，怎么解决的呢
10:34:05 张起坤
原因就是我们有个维护常驻服务的代码写错了，导致每3分钟都会新建一个常驻服务
10:34:32 张起坤
常驻服务GC是回收不掉的
10:34:49 张起坤
然后内存就会一点一点的涨
10:35:23 张起坤
直到分配的内存满了，而且也回收不掉，然后应用就假死在那里了
10:36:11 donson
线程dump应该会看到大量的常驻线程
10:38:50 王亮
10:38:51 王亮
10:38:52 王亮
10:40:22 张起坤
JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解 - wisgood的专栏 - CSDN博客
10:40:28 忘忧草
消除反接，拥抱网联
10:43:03 张起坤
@张文-58-技术?看一下jvm工具，可以用eclipse分析一下，起码会帮你逐步找到问题。要不然只能硬分析代码了
10:44:04 张起坤
短期的小上调jvm的内存分配大小，保证系统可以稳定跑着
11:06:00 陈鹏
@王亮-收银家-研发?开会的图，再更新点吧[奸笑]
11:07:40 王亮
我也是转发的，群里有去银联开会的多发一下??
11:19:44 donson
httpclient 4.x路由线程有了解的吗
21:07:20 罗志威
以太零将于1月19日正式硬分叉-史诗级变革终于来了_金色财经