线上服务异常的定位、处理与优化的探索 - 第七章 总结

一.1. 如何减少线上服务问题

 

1. GC部分

v 尽早释放不使用的对象，特别注意一些复杂的数组、队列这些对象之间关系复杂相互引用，GC回收他们效率较低。如果程序允许，尽早将这些对象赋值为null让GC尽快回收。

v 尽量不使用finalize函数，finalize能提供一个释放对象或资源的机会，但同时也会加大GC工作量。

v 特别注意循环线程。当一个或多个线程在一个死循环中执行时，会尽可能的消耗CPU周期，造成应用程序挂起其他请求无响应现象。

v 当Eden区和Old区增长很快但GC的回收效率却越来越小时，警惕JVM内存出现异常。

v 依据GC的特性MinorGC远比FullGC效率高，警惕连续长时间出现FullGC，说明内存中老年代对象急剧增多，有可能出现内存溢出。

v 系统出现在规律时间内出现经常性的卡顿，优先检查FullGC次数和平均时间，以及CPU的使用率是否存在居高不下情况。

v 警惕FullGC的时间，假设FullGC平局耗时3秒，而应用又设置数据库TimeOut时间是1秒，则日志会出现频繁的超时现象。

v 不建议盲目调整新生代与老年代比例(NewRatio)，老年代过多可能引起FULL GC时间消耗过长，导致服务器出现经常性的卡顿。

v GC收集垃圾时会暂停所有业务线程，所以警惕FullGC的时长和永久代的大对象，FullGC的时间过大容易引起系统出现卡顿的现象，处理此类问题一般将服务拆解，或多节点部署，减少FullGC次数和时间。

2. 操作系统部分

v 在一段有规律的时间内应用的吞吐量出现长时间明显的忽高忽低时，使用netstat –an 命令查看网络连接，如果出现很多TIME_WAIT的连接说明应用的处理速度大于TCP连接的释放速度，需要修改TIME_WAIT参数来减少TCP连接断开等待时间

修改/etc/sysctl.conf文件，重启系统后生效。新增内容如下：

net.ipv4.tcp_tw_reuse=1

net.ipv4.tcp_tw_recycle=1

net.ipv4.tcp_syncookies=1

v 出现OutOfMemoryError时，有一种是本机内存错误(Out of swap space)，说明系统交换空间不足，可能由于操作系统的配置问题所导致，或由于系统中的另一个进程消耗过多内存，需要加大操作系统交换分区

Linux：开设swap分区，大小办物理内存的一到两倍

Windows：增加windows虚拟内存

 

3. 数据库连接池

v 数据库连接池究竟要开多少？有限的资源里并不是越大越好，应用可能只需要很小的一个连接池。

https://mp.weixin.qq.com/s/3VwyKfqVXZX5NodnOatovA

 

4. 监控与运维

v 大型项目和战略项目上，建议投入运维监控资源，主动对系统不间断的实时监控，实时反馈系统状态，保证系统业务持续稳定的运行，而不是被动的告警。发现问题能及时定位，及时快速解决，减少故障率，避免影响扩大。

一.2. 总结与建议

 

线上服务出现问题是一个无法避免和回避的问题，本地调试的千好万好上线也运行难免出现问题。

v 日常排查生产服务问题时，可以使用多种组合方式排查，在没有配置图形界面化的工具时，同样可以使用JVM内置的命令排查问题，有条件的可以引入图形界面化的工具更容易分析数据。

v 个别功能/服务出现性能、耗时长等问题优先建议使用JProfiler排查CPU View分析性能瓶颈。

v 宕机/内存溢出等如果仅有几次出现后又恢复正常，建议配置内存溢出自动导出Dump，或者直接使用JMap导出Dump，再使用MAT或VisualVM分析。

v 频繁出现宕机现象，建议组合方式排查。优先使用jstat分析GC频率、时间、日志，通过逐渐调整JVM参数调优，逐渐达到稳定状态，同时也有必要生成堆快照分析内存是否存在大对象问题，以及查找是否存在死锁等。

v 基于JDK8版本和以上的应用，堆内存并不是设置的越大越好。在大量使用NIO操作时需要注意堆外内存空间的剩余。

一.3. 结语

 

本课题内容参考了《深入了解Java虚拟机》、《Thinking in Java》、《Linux入门很简单》以及超过100小时的视频教程学习、多个项目实际案例总结而成。

从基础的Java虚拟机模型到常用分析工具，再到模拟场景问题的处理以及监控运维平台的作用，分别详尽了线上服务问题的底层问题分析、常用处理工具、预防补救措施等。 其中部分章节由于篇幅和时间有限未能详细和深入的阐明具体作用和使用方式是课题的一个重要遗憾点。希望课题能够对未来项目上发生的问题给到合适的启发和帮助。