ARTIFACTORY:我如何从线程转储和顶级命令中找到导致高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(s): 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内存:104744.0 total, 10623.0 free, 65839.5 used, 28281.6 buff/cache
MiB Swap: total 0.0, free 0.0, used 0.0。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 00:00 .86 top
18714 root 20 0 11.9g 1.8g 23024 S 2.1 1.8 1:23.68 C2编译器
10078 root 20 0 11.9g 2.0g 23320 S 1.8 1.9 0:00.06 C2编译器
2289 root 20 0 3928740 2.0g 9812 S 1.2 1.9 4:58.48 sqlservr
15310根20 0 12.0g 2.0g 12216 S 1.2 2.0 0:51.31 logback-watchdo
20687 message+ 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 compiler3
9566根20 0 2635928 283216 66024 S 0.9 0.3 0:02.04 jf-analysis
9679 root 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 root 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的支持案例来进一步调查，从而采取行动解决问题。