记一次线上机器CPU飙高的排查过程

        公司如今把小贷机器都整理回收了，访问量不大，基本都是用户来查看账户进行还款操作。

        现在情况是，我们把很多服务都放在了一台服务器上，那天线上环境改了auth的salt，本地这边是写死的，自动上线已经关闭了通道，没辙，手动替包手动上线，结果没多久运维就喊了，表示cpu飙高到300%。

        难得的机会，先用top找出cpu占用最多进程

如果想细看进程信息可以使用ll proc

其实运行完这里的时候，我比较吃惊的是，真正占CPU的并不是部署的几个服务，而是resin容器本身，飚到了99%，从这个角度来讲，其实大部分性能问题都是垃圾回收的锅。

然后利用ps查看到的进程pid找cpu最高线程

然后拿着线程tid在jstack找，结果在里面找不到，然后上网查JAVA线程无法在jstack里找到的原因

以上大概意思是没找到线程的跟踪栈有三种情况，就是线程启动前的预启动，以及线程退出后的cleanup，第三种就是，利用JVM TI agent运行的线程，这个线程是用来跑本地code的。

******这里面都提到了JVM TI技术，这个技术主要是用来提供虚拟机调用本地方法的接口，可以获取jvm运行情况和提供本地方法的后门一样的接口工具，一些调试和诊断工具都是基于JVM TI来实现的，很多JVM都有自己的TI实现。

当然，这个Stack Over Flow的答案针对的Java线程，我所知道的是，如果导致我们CPU飙高的并不是java线程，那么jstack -F就打不出来。

而这个jstack -m模式，在官方文档里是说，可以打印出所有Java线程和native frames的所有线程。其实到这里是不是隐隐感觉到什么了~~没错，最后真的是垃圾回收的锅。

然后jdk8利用jstack -m找到了，发现里面使用的方法是CMS垃圾回收器的方法

讲真，平时只负责上下线，JVM配置只要不出问题很少留意，这个年代了，还在使用CMS吗？嗯，jmap看了下，是CMS。而占用大多CPU也是CMS的特性之一：最小化GC中断，付出的代价便是高CPU负荷。

既然定位到了垃圾回收，那就接着排查垃圾回收吧，pid是18637

就去jstat -gc 18637 5000

jstat -gcold 18637

jstat -gcoldcapacity 18637

发现full gc非常频繁（每五秒输出，发现触发fullGC13次）

（复盘这次的排查问题，发现图片保存少之又少。。）

如此频繁，顺带gccause一下看看最近一次回收的原因

结果长这样

从这个结果来看最近一次是Metadata的GC，而触发原因是因为达到了阈值。再细看当前元空间使用率已经接近98%。

到这里不能等了，找运维拿来了jvm参数，有三个参数很亮眼

老年代的配置属于默认配置，占整个堆内存的2/3，CMS回收要达到80%才会触发，我们还没有达到这个值。

那么根据图1中的显示，metaspace我们已经达到了阈值。

这种情况产生也没毛病，想想一台机器部署了5个web服务和5个微服务的场景吧，虽然没什么人访问，但加载的class信息也足够多了。

主要就是metadata的配置，而有关metadata的配置并没有oracle的官方指导，官方指导上的意思是说metaspace的配置，主要是避免首次启动时对加载的类信息做回收，取决于应用本身，够用就行了，不要太频繁触发full gc就好

其实调大这metaspace的配置能够大概解决问题，但是最终我选择了切换为G1垃圾回收。

官方文档是这样写的

        首先戳我的点的主要原因是g1最终的目的是要取代cms垃圾回收器，它的回收范围是整个堆，紧跟潮流总不会错的。其次g1取代cms的情况官方也建议了以下几点：

1. 一个是要管理的堆内存大于6g

2. 一个是服务已使用的堆内存超过了50%

3. 一个是对象分配率过高或对象从新生代晋升到老年代速率过快（这里我查了一下资料，意思是对象分配率过高的话其实会导致Minor GC频繁，而这种情况会使对象更快地晋升到老年代，而老年代如果过快地被填充，又会触发FullGC。从设计角度来讲，之所以分代回收，是为了应对对象存活时间而使用不同的回收策略，老年代可不是为了频繁回收而产生的）

4. 垃圾回收导致服务中断时长超过0.5-1s。

这种时候官方就建议把cms换成g1了。

        最终cpu骤降，从99%降至一般运行状态下的2%左右。好了。就这样吧，虽然不希望线上出现这种问题，但一旦出问题了，搞一遍还蛮带感的。期待下一次的摸排：DDDDD

后记：

        最近在复盘这次垃圾回收，因为这次jvm排查的经历让我对垃圾回收机制和分代回收这一块加深了印象。复盘的时候发现自己思考地还欠缺深入。这次的问题有两个地方值得深思，一个是为什么metaspace会超？如果正常进行GC，为何会超出阈值？其次是没有调大metaspace的前提下，换成G1为什么就没有再频繁FullGC过？

        为什么metaspace会超，我经过比对当时留下CMS的jstat数据和G1当前的数据，发现新生代CMS划分区域非常大，是现在G1的十倍。G1是不建议设定新老年代比例的，这样它就可以动态调整新老年代比例，达到最优实践。首先说明metaspace是存储类描述信息的，当堆上分配了对象，就会关联到metaspace里面的类信息，如果堆上的对象不回收，那么metaspace里面的类信息也不会回收。

        在配置cms时，我们会设置新生代老年代比例，新生代空间是固定的，如果新生代的空间比较大，回收间隔时间长，那就会导致metaspace里的class信息无法被释放，最终导致未进行youngGC而率先因为metaspace超了跑了FullGC。但G1的新生代空间是根据使用情况动态分配的，它的算法会去回收最有回收价值的region。

        就这次修改参数而言，使用G1比CMS时间短很多，就已经执行了717次youngGC，而CMS用了那么久，才52次，侧面也能佐证这个猜测的正确性，解释了为何在相同metaspace的配置下，G1没有产生频繁FullGC的原因：新生代对象回收加快，metaspace空间得到了尽快释放，没有达到阈值，于是不会触发FullGC。

参考文献：

* https://www.oracle.com/java/technologies/javase/hotspot-garbage-collection.html

* https://www.oracle.com/java/technologies/javase/gc-tuning-6.html

* https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/sizing.html

* https://plumbr.io/blog/garbage-collection/what-is-allocation-rate

* https://plumbr.io/blog/garbage-collection/what-is-promotion-rate

服务器搭建VPN方法

-

1、打开[控制面板] –>[管理工具] –>[路由和远程访问]

2、选中[配置并启用路由和远程访问]

3、选中[自定义]，因为你只有一块网卡嘛，所以选中第一项或第三项的话，你会得到一个“必须两块网卡”的提示

4、选中[VPN访问]，启动系统服务 稍等即可

5、选中[属性]

6、在弹出的控制面板中选中[IP] –>[静态地址池] –>[添加] 然后输入个起始IP [192.168.0.1] 结束IP [192.168.0.254]，这个IP段192.168.1.1-192.168.1.254都一样的都可以，是给拔入你的VPN服务器的客户端分配 的虚拟IP

7、然后鼠标右击[静态路由]–>[新建静态路由]

8、[接口]选“本地连接”，目标[0.0.0.0]，网络掩码[0.0.0.0]，网关输入你的网卡上TCP/IP协议里的那个网关(看网上 邻居的IP协议)，这一步很重要，不然你的VPN服务器客户拔入后，只能访问你的服务器，不然再访问其它网络。QQ之类的就不能用了

查看网上邻居，得到他默认的网关

9、然后删除[DHCP 中继代理程序] 中的[内部]

10、然后鼠标右击[DHCP 中继代理程序] 在弹出式菜单中[新增接口]本地连接

11、选中[本地连接]

12、完成以上后，鼠标右击[常规] –>[新增路由协议]

13、选中[NAT/基本防火墙]

14、加完后，你就会在左例表中看到[NAT/基本防火墙]，鼠标右击[NAT/基本防火墙],选中弹出式菜单中[新增接口]

15、选中[本地连接]

16、在面板中选择[公用接口连接到 Internet] –>[在此接口上启用NAT] ，如果你WINDOWS 2003中使用了系统自带的防火墙的话，请在[服务和端口]，中要使用的服务打上勾，如果你不太清楚的话，那就全打上勾.

17、然后建立一个VPN帐号，允许拨入，设置允许访问。

18、全部完成，然后使用VPN拔号软件连入就行了完成了。

特约撰稿郑瑜本报记者何莎莎北京报道

一场关于虚拟货币以及ICO（Initial Coin Offering，即首次币发行）的整顿清理措施正在进一步升级。

针对虚拟货币和ICO的监管，据悉国家互联网金融风险专项整

治小组办公室（以下简称“整治办”）将对124家服务器设在境外，但实质面向境内居民提供交易服务的虚拟货币交易平台网站采取必要管控措施；加强对新摸排的境内ICO及虚拟货币交易相关网站、公众号等处置；从支付结算端入手持续加强清理整顿力度。目前，各地摸排出的国内88家虚拟货币交

易平台和85家ICO平台基本实现无风险退出。

8月21日晚间，大批“币圈”自媒体公众账号被封禁。《中国经营报》记者从腾讯官方了解到，此次封停原因为“部分公众号涉嫌发布ICO和虚拟货币交易炒作信息，违反《即时通讯工具公众信息服务发展管理暂行规定》，已被责令屏蔽

所有内容，账号被永久封停。”

另类投资专家、币策首席分析师肖磊在接受记者采访时表示，目前有一些虚拟货币在自媒体的宣传之后，价格不止跌20%、30%，而是甚至跌去70%、80%，当然有行情熊市的原因，但也不排除有蓄意牟利的行为。“有些币在散户高位接盘之后可以说是腰斩了。”

整顿升级

自去年央行宣布开始调查国内三大比特币交易平台以及央行等七部委发布通知叫停ICO融资后，国内虚拟币市场整顿已初见成效。今年4月23日，中国银保监会称所有ICO平台和比特币交易已经安全退出中国市场。

不过，针对币圈的有关监管一直没有放松。而整治办在加码排查涉ICO及虚拟币方面，也将进一步采取针对性清理整顿措施。

一是对124家服务器设在境外，但实质面向境内居民提供交易服务的虚拟货币交易平台网站采取必要管控措施，下一步将加强监测，实时封堵。

二是加强对新摸排的境内ICO及虚拟货币交易相关网站、公众号等处置。对于定期摸排发现的境内ICO及虚拟货币交易场所网站、公众号，以及为上述活动提供支持和服务的公众号、自媒体及网站，及时予以关闭和查封。

三是从支付结算端入手持续加强清理整顿力度。多次约谈第三方支付机构，要求其严格落实不得开展与比特币等虚拟货币相关业务的要求。指导相关支付机构加强支付渠道管理、客户识别和风险提示，建立监测排查机制，停止为可疑交易提供支付服务。

这次升级整顿已见行动和成效。8月21日晚间，金色财经、币世界等公众号被责令屏蔽所有内容，账号被永久封停。

各地在清理整顿工作中也稳步推进。近日，江苏省金融办全面梳理省内各类金融风险，向13个设区市政府分别发函，提示包括特定风险点在内的风险，督促逐一建档、逐项处置。持续深入开展互联网金融风险专项整治，整治领域拓展到虚拟货币、ICO、校园贷、现金贷等，对摸底排查阶段确定的重点对象进行现场检查和处置。而北京朝阳区金融办也下发了《关于禁止承办虚拟币推介活动的通知》。

事实上，早在2013年央行等五部委就曾发布《关于防范比特币风险的通知》，界定比特币是一种虚拟商品，不是真正意义的法币，并要求金融机构和支付机构不得直接或间接为客户提供其他与比特币相关的服务等。去年七部委发布《关于防范代币发行融资风险的公告》提出，“任何所谓的代币融资交易平台不得从事法定货币与代币、‘虚拟货币’相互之间的兑换业务，不得买卖或作为中央对手方买卖代币或‘虚拟货币’，不得为代币或‘虚拟货币’提供定价、信息中介等服务。”

北京金诚同达律师事务所律师张烽对此表示，“这些监管措施基本上都可以在过去央行等有关部委发布的相关文件中找到相应依据，这次是进一步的重申与确认。”

---