本篇文章給大家分享的是有關怎么解決線上服務器CPU占用率高如何排查定位問題,小編覺得挺實用的,因此分享給大家學習,希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。
定位進程
登錄服務器,執行top命令,查看CPU占用情況:
$top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1893 admin 20 0 7127m 2.6g 38m S 181.7 32.6 10:20.26 java
top命令是Linux下常用的性能分析工具,能夠實時顯示系統中各個進程的資源占用狀況,類似于Windows的任務管理器。
通過以上命令,我們可以看到,進程ID為1893的Java進程的CPU占用率達到了181%,基本可以定位到是我們的Java應用導致整個服務器的CPU占用率飆升。
定位線程
我們知道,Java是單進程多線程的,那么,我們接下來看看PID=1893的這個Java進程中的各個線程的CPU使用情況,同樣是用top命令:
$top -Hp 1893
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4519 admin 20 0 7127m 2.6g 38m R 18.6 32.6 0:40.11 java
通過top -Hp 1893命令,我們可以發現,當前1893這個進程中,ID為4519的線程占用CPU最高。
定位代碼
通過top命令,我們目前已經定位到導致CPU使用率較高的具體線程, 那么我么接下來就定位下到底是哪一行代碼存在問題。
首先,我們需要把4519這個線程轉成16進制:
$printf %x 4519
11a7
接下來,通過jstack命令,查看棧信息:
$sudo -u admin jstack 1893 |grep -A 200 11a7
"HSFBizProcessor-DEFAULT-8-thread-5" #500 daemon prio=10 os_prio=0 tid=0x00007f632314a800 nid=0x11a2 runnable [0x000000005442a000]
java.lang.Thread.State: RUNNABLE
at sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:684)
at sun.misc.URLClassPath.findResource(URLClassPath.java:188)
at java.net.URLClassLoader$2.run(URLClassLoader.java:569)
at java.net.URLClassLoader$2.run(URLClassLoader.java:567)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findResource(URLClassLoader.java:566)
at java.lang.ClassLoader.getResource(ClassLoader.java:1093)
at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:232)
at org.hibernate.validator.internal.xml.ValidationXmlParser.getInputStreamForPath(ValidationXmlParser.java:248)
at org.hibernate.validator.internal.xml.ValidationXmlParser.getValidationConfig(ValidationXmlParser.java:191)
at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:65)
at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:287)
at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:174)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
at com.test.common.util.BeanValidator.validate(BeanValidator.java:30)
通過以上代碼,我們可以清楚的看到,BeanValidator.java的第30行是有可能存在問題的。
3
問題解決
接下來就是通過查看代碼來解決問題了,我們發現,我們自定義了一個BeanValidator,封裝了Hibernate的Validator,然后在validate方法中,通過Validation.buildDefaultValidatorFactory().getValidator()初始化一個Validator實例,通過分析發現這個實例化的過程比較耗時。
我們重構了一下代碼,把Validator實例的初始化提到方法外,在類初始化的時候創建一次就解決了問題。
4
總結
以上,展示了一次比較完成的線上問題定位過程。主要用到的命令有:top 、printf 和 jstack
另外,線上問題排查還可以使用Alibaba開源的工具Arthas進行排查,以上問題,可以使用一下命令定位:
thread -n 3 //查看cpu占比前三的線程
以上就是怎么解決線上服務器CPU占用率高如何排查定位問題,小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。