TongWeb生产系统应急处理方案

前言

本文档主要说明在上线正式运行的系统中，现场维护人员或在现场的 TongWeb 支持人员应急处理方案。

一、基本原则要求

运维人员需要具备Linux基本操作、Linux监控命令、TongWeb使用、Java编程、Java异常分析、jstack、jmap、jstat、MemoryAnalyzer等工具和命令的使用。
任何操作必须经过相关负责人同意后进行，禁止在未允许的情况下做任何操作。
在重启 TongWeb 前，需花费几分钟收集相关日志，切记盲目重启 TongWeb 导致无法收集日志，事后无法分析问题。

二、license 过期情况

TongWeb 的 license 过期后会凌晨6点自动停止，请联系东方通商务人员索要TongWeb 产品的 license。并提前进行替换，见：https://blog.csdn.net/realwangpu/article/details/109611636
应用的 license 过期，请尽快联系应用开发商索要产品的 license。
SSL 证书过期，请尽快联系证书公司索要新的证书。

三、低级误操作问题

操作系统、数据库、应用、TongWeb、网络不做基本优化，直接上线。
linux下采用不同用户启动TongWeb导致文件权限问题。需采用 chown -R [TongWeb用户]:[TongWeb组] [TongWeb目录] 命令改变TongWeb目录文件属主。
需采用nohup后台启动TongWeb，如：nohup ./startserver.sh & 或 ./startservernohup.sh , 域启动 nohup ./startdomain.sh 域名 & 。
系统运行过程中更改应用、TongWeb配置导致访问中断。
每次重部应用后，需重启TongWeb，否则容易导致问题，见：https://blog.csdn.net/realwangpu/article/details/109510297

四、TongWeb已经停止，Java 进程已经不存在的情况

迅速打包保留 TongWeb 的 logs 目录日志和 bin 下的 nohup.out 文件，并记录这些文件的时间，以判断 TongWeb 是何时停止的。
检查TongWeb bin目录下是否生成javacore*、hs*、core*、heapdump*开头的文件，保留这些文件分析问题。
立刻启动 TongWeb，恢复系统。

五、应用系统某些功能点无法使用

应用系统有的功能点能用，有的不能用。出现这种情况注意查看 TongWeb 的日志是否存在异常信息，肯定是因为应用有异常才不能用的。若日志中无任何异常信息，则需要在应用中加入调试信息或打开应用的 DEBUG 日志，再收集异常日志分析问题。

六、应用系统慢或假死的情况

出现这种情况最忌讳的是运维人员盲目重启系统解决问题，然后得出结论：重启TongWeb可以解决问题，所以就是TongWeb的问题。实际情况为：TongWeb与应用同在一个JVM进程中共享资源，所以出问题重启TongWeb后，TongWeb与应用的资源都会清理掉并重建。这种方式可以恢复应用，但并不表明为TongWeb问题。正如当电脑、手机不好用时，可重启机器来解决问题，但并不能确定是哪方软、硬件造成的。正确的处理方式如下：

第一步：先观察慢的现象

现象一：通过top命令查看TongWeb的java进程占用CPU是否高。若CPU高则通过TongWeb的bin目录下的thread-profiler.sh来分析。

现象二：通常表现为CPU使用不高，TongWeb控制台访问正常，但应用所有页面访问都慢或不能访问应用端口，这种情况通常是应用的http线程池大部分出现阻塞导致的。通过jstack或kill -3分析。

现象三：通常表现为CPU使用不高，TongWeb控制台访问正常，但应用跟数据库无关的页面访问正常，跟数据库有关的页面访问慢。查看日志和数据源配置。

现象四：TongWeb控制台和应用访部都很慢，日志中有“OutOfMemoryError”但进程还在。通过GC日志或jstat命令，查看内存是否占满，Full GC是否频繁。

现象五："大部分业务正常，只有个别业务慢"，这是应用该部分业务的问题，与中间件无关。推荐TongAPM、阿里开源的 java 诊断工具-Arthas，可做源码级性能分析。

第二步：根据不同的现象在重启前收集日志，并进行具体分析，见：https://blog.csdn.net/realwangpu/article/details/109442393

第三步：收集完以上信息后，根据维护负责人员意见，看是否需要重启 TongWeb 快速恢复生产系统。

最糟糕的情况是说不清以上慢的情况，出问题时着急重启TongWeb解决没有收集日志。这种情况下，只能将TongWeb该开启的日志全开启，企盼在出现问题时能尽量抓取的日志全些。对TongWeb进行以下配置：

1. 在bin/external.vmoptions文件中打开GC日志和生成内存溢出镜像的参数。

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=../logs/heap`date +%Y%m%d%H%M`.hprof
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-Xloggc:../logs/gc`date +%Y%m%d%H%M`.log

2. 修改快照生成默认值，只生成jstack日志。若http最大线程数设300, 则可在快照的通道设置中将该http通道“最大线程数”设为250。在线程使用量高时打出jstack。

3. 开启超时线程日志，在server.log中记录该线程栈信息。

[2021-03-29 14:13:16 977] [INFO] [ThanosStandardService hung thread check [1174290147:1616998336906]] [core] [Request Info: Url=http://127.0.0.1/dbpool/ Parameters
Thread Info: "http-nio2-0.0.0.0-80-exec-2" id=223 state=TIMED_WAITING
    - waiting on <0x067b630c> (a java.util.concurrent.SynchronousQueue$TransferQueue)
    - locked <0x067b630c> (a java.util.concurrent.SynchronousQueue$TransferQueue)
    at sun.misc.Unsafe.park(Native Method)
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
    at java.util.concurrent.SynchronousQueue$TransferQueue.awaitFulfill(SynchronousQueue.java:764)
    at java.util.concurrent.SynchronousQueue$TransferQueue.transfer(SynchronousQueue.java:695)
    at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941)
    at com.tongweb.hulk.util.ConcurrentBag.borrow(ConcurrentBag.java:137)
    at com.tongweb.hulk.pool.HulkPool.getConnection0(HulkPool.java:148)
    at com.tongweb.hulk.pool.HulkPool.getConnection(HulkPool.java:118)
    at com.tongweb.hulk.pool.HulkPool.getConnection(HulkPool.java:113)

4. 若采用TongWeb数据源，则开启“泄露日志”，“SQL日志”。开源连接池也可以开启泄露。

5. 如果还会操作些命令，在TongWeb机器上通过"netstat -an|grep http端口"，在数据库机器上通过"netstat -an|grep 数据库端口"查看端口状态。

6. 如果还会操作些命令，执行bin下 ./thread-profiler.sh -p <Java进程ID> -c 500 -a cpulog.txt 。

最后提供收集日志给相关人员，并说明出现问题的时间点，提供logs下所有日志，以及1-6步产生的日志。千万别只会说一句：重启就没事了。