如何从线程转储和top命令中找到导致高cpu的原因?

在某些情况下，您可能会遇到cpu过高的情况，需要找出导致利用率增加的原因。有一种方法可以从线程转储和top的输出(都是在高CPU期间获得的)中找出导致高CPU的原因，您可以自己采取行动或使用JFrog Support打开一个案例。

为此，首先，在问题发生期间进行线程转储。中所示，可以进行线程转储这篇文章。同样，在这个问题中，收集“top -H”的输出，以查看顶级cpu消耗进程。

输出应该如下所示:Top - 16:55:45上升141天，22:41,1个用户，平均负载:2.13,1.84,1.95
线程:12261总，3运行，12258睡眠，0停止，0僵尸
Cpu: 5.6 us, 3.0 sy, 0.0 ni, 90.0 id, 0.2 wa, 0.0 hi, 1.2 si, 0.0 st
MiB Mem: 104744.0 total, 10623.0 free, 65839.5 used, 28281.6 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used。35619.5 avail MemPid user pr ni virt res SHR s % cpu % mem time +命令
9983 mattheww 20 0 25360 17808 3376 R 8.8 0.0 0:00.86顶部
18714 root 20 0 11.9g 1.8g 23024 S 2.1 1.8 1:23.68 C2 CompilerThre
10078 root 20 0 11.9g 2.0g 23320 S 1.8 1.9 0:00.06 C2 CompilerThre
2289 root 20 0 3928740 2.0g 9812 S 1.2 1.9 4:58.48 sqlservr
15310 root 20 0 12.0g 2.0g 12216 S 1.2 2.0 0:51.31 logback-watchdo
20687消息+ 20 0 9642768 104228 6488 S 1.2 0.1 0:49.86 1_scheduler
6573 root 20 0 11.9g 2.0g 23320 S 0.9 1.9 2:10.37 C2 CompilerThre
9566根20 0 2635928 283216 66024 S 0.9 0.3 0:02.04 jf-analysis
9679根20 0 2635928 283216 66024 S 0.9 0.3 0:03.52 jf-analysis
9691根20 0 2635928 283216 66024 S 0.9 0.3 0:02.07 jf-analysis
12690根20 0 2635928 283216 66024 S 0.9 0.3 0:01.64 jf-analysis
17599 root 20 0 12.0g 2.0g 12216 S 0.9 2.0 0:05.33 jf-access-task4
然后，取占用cpu最多(或最多几个)的进程的pid。转换PID变成十六进制。例如，对于PID 264969，可以得到40b09的十六进制值。

之后，在线程转储中，寻找具有十六进制值的“nid”。它应该如下图所示:"http-nio-8081-exec-1561" #387225 daemon prio=5 os_prio=0 cpu=2378534.00ms elapsed=104871.01s tid=0x00007f60380e4800 nid=0x40b09 runnable [0x00007f58d7ebb000]
java.lang.Thread.State:可运行
com.google.common.cache.LocalCache.get (LocalCache.java: 3951)
com.google.common.cache.LocalCache.getOrLoad (LocalCache.java: 3974)
com.google.common.cache.LocalCache LocalLoadingCache.get美元(LocalCache.java: 4935)
org.jfrog.storage.binstore.providers.cache.fs.ConcurrentReadCacheMissHandler.handleCacheMiss (ConcurrentReadCacheMissHandler.java: 64)
org.jfrog.storage.binstore.providers.FileCacheBinaryProviderImpl.getStream (FileCacheBinaryProviderImpl.java: 140)
org.artifactory.addon.federated.binary.FederatedBinaryProvider.getStream (FederatedBinaryProvider.java: 194)
org.artifactory.storage.db.binstore.service.BinaryServiceImpl.getBinary (BinaryServiceImpl.java: 491)
从上面的线程转储示例中，我们可以确定这个与cache-fs相关的线程导致了高cpu。

现在，您可以采取行动，通过删除cache-fs来解决这个问题，并使用JFrog support打开一个支持案例来进一步调查。