Netty,1W socket,100msg/s 广播， 30%cpu,5G 内存。

这么耗内存啊

很不正常哦，用了什么优化方法？

1W就这么大内存了么

http://www.infoq.com/cn/articles/netty-million-level-push-service-design-points
早上刚看的文章，送你了，不谢，

@jones 真是太感谢了

@otmb 完全不知道该如何解决。

@zeeler 各种改代码，各种改jvm参数

@cpp255 就是。。。

@yxaaa123 这个直接做几次heap快照，然后对比分析一下内存中什么对象占据大量内存，什么对象数量增长快速且高举不下挺容易的吧，先定为问题然后在有针对性的排查代码比较好，另外你一个JVM进程5G内存也不合适啊，FULL GC一次得要多长时间啊，建议你把GC日志打开，选择合理的GC策略同时关注每次GC的停顿时间和回收率，还有尽量避免FULL GC，在我印象中好像JVM堆内存超过2G就要考虑JVM多进程集群了，超大堆内存如果不发生FULL GC还好，一旦发生FULL GC光停顿时间就会让人崩溃，搞不好几十秒时间不响应，在对响应时间要求苛刻的场景超大堆内存根本玩不转,CMS也不行，估计G5还有希望搞定，但是目前应该还没人把G5用到生产环境

@jones 之前一直没有接触过java这种级别的调优，netty也没怎么用过，然后第一次压测直接侧漏了。现在16G内存1W连接的广播内存半分钟就干到30%，估计没等full gc就直接挂了。后来改了代码改了jvm参数有了点儿好转，但是依然分分钟暴毙的状态。。

开Jconsole看看到底是什么原因？

解决了么？后续没了啊

@jones 看到过一篇文章 tame java gc 。作者提到在大内存下，cms表现优于g1。作者提到在16g下，一般可以把gc控制在150ms左右。不过他的场合是读多写少。一次写只会更改部分数据。

如果有full gc，尽量控制在非繁忙时发生。

总的来说好像用多个jvm比较靠谱一点。