Wildfly 10.1消耗所有核心

Question

我们最近将我们的银行应用程序从Java1.6升级到1.8，并将JBoss4.x升级到WildFly10.1。

我们观察到java消耗了机器上可用的所有内核（10）。

有人能说出是什么原因吗，在JBoss4.x中，通常最大CPU利用率是4个核心。

下面是（添加到消耗高cpu的进程上）的结果

pS-elo pid,lwp,nlwp,ruser,pcpu,stime,etime,argsgrep 3630

下面是每个占用高cpu的LWP的十六进制

对于LWP 7249

下面是完整线程转储线程转储的链接

服务器不稳定，所以我们不得不返回到JDK1.6和JBoss4。我想知道JBoss4的一切工作都很完美，但现在我无法确定问题出在哪里，不管是wildfly设置，还是我的应用程序或GC设置。

线程转储分析线程转储分析结果链接

代码KycPictureServlet

@Override
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    ServletOutputStream out = null;
    FileInputStream fin = null;
    BufferedInputStream bin = null;
    BufferedOutputStream bout = null;
    try {

        String filename = String.valueOf(request.getParameter("fileName"));
        String folderPathId = String.valueOf(request.getParameter("folderPathId"));
        String kycDocPath = "";
        System.out.println("Folder Path : " + folderPathId + " \t" + filename);
        if (folderPathId != null && !folderPathId.equals("null")) {
            kycDocPath = new StoragePathService().getStoragePathByPathID(Integer.parseInt(folderPathId)).getFolderPath();
        } else {
            kycDocPath = new StoragePathService().getStoragePathByPathID(EkoDBConstants.KYC_FILE_UPLOAD_PATH).getFolderPath();
        }
        String uploadFolderPath = kycDocPath;
        final String filetofetch = uploadFolderPath + filename;

        if (filetofetch.toLowerCase().endsWith("pdf")) {
            response.setContentType("application/pdf");
            // response.setHeader("Content-Disposition", "inline;
            // filename=\"" + filetofetch + "\"");
        } else if (filetofetch.toLowerCase().endsWith("tif") || filetofetch.endsWith("tiff")) {
            response.setContentType("image/tiff");
        } else {
            response.setContentType("image/jpeg");
        }

        File uploadFolder = new File(filetofetch);
        if(uploadFolder != null && uploadFolder.exists()){

        out = response.getOutputStream();
        fin = new FileInputStream(filetofetch);
        bin = new BufferedInputStream(fin);
        bout = new BufferedOutputStream(out);
        int ch = 0;
        ;
        while ((ch = bin.read()) != -1) {
            bout.write(ch);

        }
    }

    } catch (Exception e) {
        e.printStackTrace();
    } finally {
        if (bin != null) {
            bin.close();
        }

        if (fin != null) {
            fin.close();
        }

        if (bout != null) {
            bout.close();
        }

        if (out != null) {
            out.close();
        }

    }
}

以前没有任何finally块，所以在异常流没有被关闭的情况下，第二件事我添加了额外的检查，以检查文件是否存在，然后只打开流。

"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007ff8dc231000 nid=0x11b6 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007ff8dc22e800 nid=0x11b5 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007ff8dc22d000 nid=0x11b4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007ff8dc22a000 nid=0x11b3 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

在线程转储中，我发现一些LWP正在消耗CPU并且没有结束

"VM Thread" os_prio=0 tid=0x00007ff8dc1e9000 nid=0x11B411af runnable 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007ff8dc01e800 nid=0x11a6 runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007ff8dc020800 nid=0x11a7 runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007ff8dc022000 nid=0x11a8 runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007ff8dc024000 nid=0x11a9 runnable 

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x00007ff8dc026000 nid=0x11aa runnable 

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x00007ff8dc027800 nid=0x11ab runnable 

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x00007ff8dc029800 nid=0x11ac runnable 

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x00007ff8dc02b800 nid=0x11ad runnable 

"GC task thread#8 (ParallelGC)" os_prio=0 tid=0x00007ff8dc02d000 nid=0x11ae runnable 

内存和GC设置

JAVA_OPTS="-Xms4G -Xmx12G -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=512m -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=1800000 -Dsun.rmi.dgc.server.gcInterval=1800000 -XX:-UseConcMarkSweepGC -XX:SurvivorRatio=6 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps  -Xloggc:/data/eko/GC.log -verbose:gc   -XX:NewRatio=2"

Answer 1

不幸的是，我的神奇水晶球坏了，所以我们不得不用线程转储来弄脏我们的手。
首先，我们需要弄清楚，是什么线程导致了Cpu负载，因为应用服务器不是单线程的。假设您在linux上，您可以使用标准ps来获取每个进程线程的cpu使用情况的详细信息：

ps-elo pid,lwp,nlwp,ruser,pcpu,stime,etime,args grep[PID_OF_YOUR_WILDFLY_PROCESS]>unixthread.txt

这里我们对列感兴趣 <罢工> NLWP lwp和PCPU。查找cpu负载最高的线程。
接下来我们需要java线程转储：在高cpu负载期间获得线程转储：

jstack-l[PID_OF_YOUR_WILDFLY_PROCESS]>jstack.out

现在进行线程搜索：假设您的unixthread将nwlp 9999的线程标识为CPU占用，将该数字转换为十六进制-0x270F，并在jstack.out文件中搜索该值。它应该与java线程匹配，并使用stacktrace来帮助您确定问题所在。

如果它与GC相关，那么继续进行堆转储，以确保它不会在您的应用程序中泄漏。
如果您进行了分析，但仍然认为它是jvm或GC设置的问题，那么您应该与redhat的人员取得联系。我相信，如果你打算在RedHat堆栈上运行一个银行应用程序，你绝对应该选择有付费支持的EAP7，而不是hazzard的上游OS项目，不支持最终的bug或问题。