当前位置 博文首页 > asd1358355022的博客：每日积累【Day 8】线上运行的项目突然变得
? 我们可能在项目部署后遇到一些问题，某一块模块功能或者全部的模块功能在某一时间段特别卡，我们应该如那些方面去排查呢？接下来我们一起去探究一下。
?
? 1、如果所有的模块都卡：
? 极有可能是网络出问题，cpu被拉满了。
? 2、如果是单一个模块的变得卡，其他模块都正常：
? 变卡的问题可能性点：文件句柄，IO流，SOCKET流，代码中sql不规范，数据库连接资源，数据库连接问题导致锁无法释放，代
码中sleep过长，线程池使用不规范等等。
? 优先查看最近的代码提交是否复合规范。
? 如果上述无法确认，线上触发调用从接口调用出开始排查日志，查看每一次关键日志的时间信息，看能否确定哪一个调用链路时
间耗费过长，查看当前文件句柄，IO流，SOCKET流是否资源关闭正常，去数据库执行当前的sql语句看是否为慢sql，是否因为少参数问
题导致全表查询。
? 如果上述还无法确定，可以在触发线上调用之后看一下当前线程的dump信息
####使用top -H指令看每个线程的性能（如果有某个线程的cpu利用率一直是100，记录下pid）
root@hadoop top -H
####将上步骤的pid转换成线程用的nid（16进制的）
printf "%x\n" 上一步的pid
###获取当前项目的java的pid
root@hadoop ps -aux | grep java
tomcat 1538 17.1 39.4 11175396 6620524 ? Sl Jul09 3629:14 /opt/taobao/install/ajdk-8.1.1_fp1-b52/bin/java -server -Xms5334m -Xmx5334m -Xss1m -XX:PermSize=128m -XX:MaxPermSize=256m -Xmn2000m -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000 -XX:+CMSParallelRemarkEnabled -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -verbose:gc -Xloggc:/alidata/www/logs/tomcat7/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:-HeapDumpOnOutOfMemoryError -XX:ErrorFile=/usr/share/tomcat7/logs/hs_err_pid%p.log -XX:HeapDumpPath=/usr/share/tomcat7/logs/java_pid.hprof -verbose:gc -Xloggc:/alidata/www/logs/tomcat7/gc.log-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Djdk.tls.rejectClientInitiatedRenegotiation=true -Dsun.net.inetaddr.ttl=0 -Dcatalina.logs=/usr/share/tomcat7/logs -Dlog4j.defaultInitOverride=true -Dlog4j.dir=/alidata/www/logs/tomcat7 -Dlog4j.level=WARN -Dproject.name=ecm-server -javaagent:/alidata/tianjimon-apm/tianjimon-apm.jar -classpath :/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar: -Dcatalina.base=/usr/share/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.endorsed.dirs= -Djava.io.tmpdir=/tmp -Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start
root 124342 0.0 0.0 61260 1864 pts/6 S+ 16:40 0:00 grep java
####使用pid dump当前运行的线程信息
root@hadoop jstack 1538 >> dump.log
####统计所有的线程状态
root@hadoop grep Thread.State dump.log| awk '{print $2 $3 $4 $5}' | sort | uniq -c
40 RUNNABLE
21 TIMED_WAITING(onobjectmonitor)
5 TIMED_WAITING(parking)
44 TIMED_WAITING(sleeping)
200 WAITING(onobjectmonitor)
3 WAITING(parking)
####如果有大量WAITING的线程，可以查看当前dump.log中WAITING的线程在干什么，如果WAITING的线程日志中有await，说明有大量线程空闲状态。如果有大量的WAITING，会造成过多的线程上下文切换次数【因为WAITING状态是等待状态，等待就绪，等待cpu调度，每一次WAITING到RUNNABLE都会进行一次上下文切换】
###将第二步骤的线程nid拿过来去dump.log查询当前线程在干什么(示例)
locked <0x00000007d0015508>，再waiting on <0x00000007d0015508>
"Finalizer" #3 daemon prio=8 os_prio=31 cpu=0.43ms elapsed=283151.83s tid=0x00007fd4b301f800 nid=0x3803 in Object.wait() [0x0000700002aba000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.10/Native Method)
- waiting on <0x00000007d0015508> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(java.base@11.0.10/ReferenceQueue.java:155)
- locked <0x00000007d0015508> (a java.lang.Object)
at java.lang.ref.ReferenceQueue.remove(java.base@11.0.10/ReferenceQueue.java:176)
at java.lang.ref.Finalizer$FinalizerThread.run(java.base@11.0.10/Finalizer.java:170)
######日志中如果能体现线程使用不合理，需要去代码中去看下线程池的使用是否规范，是否有代码不合理的地方
?
cs