在线咨询

java web服务器cpu占用过高的处理


平时项目中有时遇到cpu过高的情况,在此基于自己有限的经验写个分享,此处的服务器都是基于linux平台。

cpu的占有线程类型总的来说分为两种:
us :用户空间占用CPU百分比
sy :内核空间占用CPU百分比
在linux下可以通过top命令查看详细,示例如下:

一般来讲CPU us高的解决方法:
CPU us 高的原因主要是执行线程不需要任何挂起动作,且一直执行,导致CPU 没有机会去调度执行其他的线程。
CPU sy高的解决方法:
CPU sy 高的原因主要是线程的运行状态要经常切换,对于这种情况,常见的一种优化方法是减少线程数。

我平时具体的步骤如下:

1.得到线程最高的几个id

ps  -eLo pid,lwp,pcpu | grep  15285|sort -nk 3   

2.导出JAVA线程栈信息

命令:kill -3 [PID] 或者 jstack

3.从栈信息中找到线程数多的几个

命令:sort  文件名 | uniq -c | sort -nk 1

4.分别分析线程数最多的前十个线程和线程占用cpu最高的前10个线程

这步是最关键的,找出这些异常点,比如某个业务功能点占用较高的cpu或者某种类型的线程数量比较多,这个和业务以及具体程序紧密关联的,在此就不多说了。

5.分析占用cpu最高的前10个线程,结果示例如下:

0x1a5:gc线程
"Concurrent Mark-Sweep GC Thread#0" prio=1 tid=0x0000002b29df1400 nid=0x1a5 runnable 
0x35f:memcache线程
"memcache5-CacheThread" prio=1 tid=0x0000002b3d277de0 nid=0x35f runnable [0x0000000042755000..0x0000000042755c30]
0x35e:memcache线程
"memcache1-CacheThread" prio=1 tid=0x0000002b371212f0 nid=0x35e runnable [0x0000000042654000..0x0000000042654cb0]
0x14e9:RMI线程
"RMI TCP Connection(102)-10.23.241.59" daemon prio=1 tid=0x0000002b37e72790 nid=0x14e9 runnable [0x000000005103c000..0x000000005103deb0]
0x1be:memcache线程
"memcache5-CacheThread" prio=1 tid=0x0000002b3dba4790 nid=0x1be runnable [0x0000000041a48000..0x0000000041a48eb0]
0x1bd:memcache线程
"memcache1-CacheThread" prio=1 tid=0x0000002b3fb70340 nid=0x1bd runnable [0x0000000041947000..0x0000000041947b30]
0x1af:jdk编译线程
"CompilerThread1" daemon prio=1 tid=0x0000002b30e11620 nid=0x1af waiting on condition [0x0000000000000000..0x000000004123f7c0]
0x1ae:jdk编译线程
"CompilerThread0" daemon prio=1 tid=0x0000002b30e10280 nid=0x1ae waiting on condition [0x0000000000000000..0x000000004113e440]
0x1684:http请求线程,通过该线程栈可以看到此处调用的是hibernate查询
"http-8080-Processor123" daemon prio=1 tid=0x0000002b37dfd9d0 nid=0x1684 runnable [0x000000005afd7000..0x000000005afdcd30]

 6.系统优化

如果找出了哪些功能点占用cpu高,接下来就需要优化了,可以从业务和技术手段两方面来进行,平时工作中比较常用的技术手段:

弹性时间:对高使用率的请求,分散到不同的时间,比如采用队列或异步,减少同一时间处理的请求。

批处理或定时任务:把请求组合成批,这样可以使得时间真真的都有效的用在了处理上,而不是网络传输等准备工作上。

缓存:将结果缓存起来,空间换时间。

7.如果是gc线程比较费时,则需要进一步的定位:

首先查看一下gc策略是否合理,然后用命令jmap -F -dump:live,file=jmap.hprof [PID] 导出内存dump文件,我一般每隔5s导一次,一共导出3次。用Eclipse Memory Analyzer分析导出来的文件,分析是哪个类占用内存比较多,分析出可能存在内存泄露的地方。

注意jvm分配内存时一个大对象的分配比多个小对象的分配效率要低,如果对象比较大,进行拆分能提高效率,具体原因如下:

Java对象所占用的内存主要从堆上进行分配,堆是所有线程共享的,因此在堆上分配内存时需要进行加锁,这导致了创建对象开销比较大。当堆上空间不足时,会触发GC,如果GC后空间仍然不足,则抛出OutOfMemory错误信息。Sun JDK为了提升内存分配的效率,会为每个新创建的线程在新生代的Eden Space上分配一块独立的空间,这块空间称为TLAB(Thread Local Allocation Buffer),其大小由JVM根据运行情况计算而得,可通过-XX:TLABWasteTargetPercent来设置TLAB可占用的Eden Space的百分比,默认值为1%。JVM将根据这个比率、线程数量及线程是否频繁分配对象来给每个线程分配合适大小的TLAB空间 。在TLAB上分配内存时不需要加锁,因此JVM在给线程中的对象分配内存时会尽量在TLAB上分配,如果对象过大或TLAB空间已用完,则仍然在堆上进行分配,因此在编写Java程序时,通常多个小的对象比大的对象分配起来更加高效。