1. sar
十載專注成都網(wǎng)站制作,成都企業(yè)網(wǎng)站建設(shè),個(gè)人網(wǎng)站制作服務(wù),為大家分享網(wǎng)站制作知識(shí)、方案,網(wǎng)站設(shè)計(jì)流程、步驟,成功服務(wù)上千家企業(yè)。為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁(yè)設(shè)計(jì)及定制高端網(wǎng)站建設(shè)服務(wù),專注于成都企業(yè)網(wǎng)站建設(shè),高端網(wǎng)頁(yè)制作,對(duì)酒店設(shè)計(jì)等多個(gè)行業(yè),擁有多年的網(wǎng)站運(yùn)維經(jīng)驗(yàn)。
每?jī)擅胨⑿乱淮危?總共5次
[root@dbhost01 ~]# sar 2 5
Linux 2.6.32-504.el6.x86_64 (dbhost01) 03/30/2018 _x86_64_ (4 CPU)
02:53:15 PM CPU %user %nice %system %iowait %steal %idle
02:53:17 PM all 0.66 0.00 1.72 0.66 0.00 96.96
02:53:19 PM all 1.34 0.00 3.35 0.80 0.00 94.51
02:53:21 PM all 0.79 0.00 1.59 1.45 0.00 96.17
02:53:23 PM all 0.40 0.00 2.00 0.80 0.00 96.80
02:53:25 PM all 0.66 0.00 1.85 0.79 0.00 96.70
Average: all 0.77 0.00 2.10 0.90 0.00 96.23
2. top
top -a 按照內(nèi)存降序
[root@dbhost01 ~]# top -a
top - 15:00:54 up 6:04, 1 user, load average: 0.31, 0.19, 0.11
Tasks: 306 total, 1 running, 305 sleeping, 0 stopped, 0 zombie
Cpu(s): 7.8%us, 2.4%sy, 0.0%ni, 88.9%id, 0.8%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 4048972k total, 3848576k used, 200396k free, 134844k buffers
Swap: 4194300k total, 1788k used, 4192512k free, 1835360k cached
3. vmstat
vmstat用于顯示虛擬內(nèi)存,內(nèi)核線程,磁盤,系統(tǒng)進(jìn)程, CPU活動(dòng)等統(tǒng)計(jì)信息。
需要安裝sysstat工具。
[root@dbhost01 ~]# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 1788 202508 135064 1835920 0 0 32 26 96 276 1 2 95 1 0
[root@dbhost01 ~]#
[root@dbhost01 ~]# vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 1788 202336 135068 1836000 0 0 32 26 97 276 1 2 95 1 0
0 0 1788 202624 135068 1836000 0 0 25 29 4012 6682 0 1 98 1 0
0 0 1788 202624 135072 1836004 0 0 57 87 4003 6685 0 1 98 1 0
1 0 1788 202508 135072 1836004 0 0 57 33 4402 7353 1 1 98 0 0
0 0 1788 202540 135076 1836004 0 0 33 47 4002 6674 0 1 98 1 0
4. lsof(list open files)
[root@dbhost01 ~]# lsof | grep 1521
certmonge 2348 root 16r FIFO 0,8 0t0 15212 pipe
certmonge 2348 root 18r FIFO 0,8 0t0 15218 pipe
gipcd.bin 2754 grid 109u unix 0xffff880139152180 0t0 36936 socket
5. tcpdump
tcpdump -i eth1
15:24:28.777779 IP dbhost01.ssh 192.168.2.82.50990: Flags [P.], seq 393080:393596, ack 105, win 148, options [nop,nop,TS val 22996360 ecr 2443327], length 516
15:24:28.777809 IP dbhost01.ssh 192.168.2.82.50990: Flags [P.], seq 393080:393596, ack 105, win 148, options [nop,nop,TS val 22996360 ecr 2443327], length 516
15:24:28.778976 IP dbhost01.ssh 192.168.2.82.50990: Flags [P.], seq 393596:393968, ack 105, win 148, options [nop,nop,TS val 22996361 ecr 2443327], length 372
15:24:28.779011 IP dbhost01.ssh 192.168.2.82.50990: Flags [P.], seq 393596:393968, ack 105, win 148, options [nop,nop,TS val 22996361 ecr 2443327], length 372
15:24:28.779013 IP 192.168.2.82.50990 dbhost01.ssh: Flags [.], ack 393968, win 16652, options [nop,nop,TS val 2443327 ecr 22996360], length 0
15:24:28.779481 IP dbhost02-priv.23602 dbhost01-priv.24271: UDP, length 556
15:24:28.779585 IP dbhost01-priv.24271 dbhost02-priv.23602: UDP, length 80
15:24:28.779909 IP dbhost01-priv.24271 dbhost02-priv.23602: UDP, length 80
15:24:28.780584 IP dbhost01.ssh 192.168.2.82.50990: Flags [P.], seq 393968:394724, ack 105, win 148, options [nop,nop,TS val 22996362 ecr 2443327], length 756
15:24:28.780590 IP dbhost01.ssh 192.168.2.82.50990: Flags [P.], seq 393968:394724, ack 105, win 148, options [nop,nop,TS val 22996362 ecr 2443327], length 756
15:24:28.780820 IP dbhost01-priv.24271 dbhost02-priv.23602: UDP, length 556
15:24:28.782232 IP dbhost01.ssh 192.168.2.82.50990: Flags [P.], seq 394724:395176, ack 105, win 148, options [nop,nop,TS val 22996364 ecr 2443327], length 452
15:24:28.782235 IP dbhost01.ssh 192.168.2.82.50990: Flags [P.], seq 394724:395176, ack 105, win 148, options [nop,nop,TS val 22996364 ecr 2443327], length 452
6.netstat
[root@dbhost01 ~]# netstat -a | grep oracle
unix 2 [ ACC ] STREAM LISTENING 31861 /var/tmp/.oracle/ora_gipc_sdbhost01gridmyracdb-clusterCRFM_SIPC
unix 2 [ ACC ] STREAM LISTENING 33820 /var/tmp/.oracle/sdbhost01DBG_LOGD
unix 2 [ ACC ] STREAM LISTENING 41177 /var/tmp/.oracle/sdbhost01DBG_EVMD
unix 2 [ ACC ] STREAM LISTENING 65106 /var/tmp/.oracle/sAevm
unix 2 [ ACC ] STREAM LISTENING 65108 /var/tmp/.oracle/sSYSTEM.evm.acceptor.auth
7. htop
需要安裝
8. iostat
Total DISK READ: 91.48 K/s | Total DISK WRITE: 45.27 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
4071 be/4 oracle 30.18 K/s 0.00 B/s 0.00 % 4.69 % ora_lmon_orcl1
4117 be/4 oracle 60.36 K/s 15.09 K/s 0.00 % 3.69 % ora_ckpt_orcl1
2989 rt/4 grid 965.71 B/s 0.00 B/s 0.00 % 2.13 % ocssd.bin
4099 be/4 oracle 0.00 B/s 30.18 K/s 0.00 % 0.07 % ora_ckpt_test
2987 rt/4 grid 0.00 B/s 482.86 B/s 0.00 % 0.03 % ocssd.bin
2979 rt/3 root 0.00 B/s 3.77 K/s 0.00 % 0.00 % ologgerd -M -d /g01/grid/app/11.2.0/grid/crf/db/dbhost01
2980 rt/3 root 0.00 B/s 15.09 K/s 0.00 % 0.00 % ologgerd -M -d /g01/grid/app/11.2.0/grid/crf/db/dbhost01
9. iftop(流量監(jiān)控工具)
1、使用ps -ef |grep 軟件名,查看您的軟件運(yùn)行時(shí)的進(jìn)程號(hào)
2、執(zhí)行l(wèi)sof -p 進(jìn)程號(hào) 看查看到你的軟件使用了哪些文件。
找到最耗CPU的java線程
ps命令
命令:ps -mp pid -o THREAD,tid,time 或者 ps -Lfp pid
結(jié)果展示:
這個(gè)命令的作用,主要是可以獲取到對(duì)應(yīng)一個(gè)進(jìn)程下的線程的一些信息。 比如你想分析一下一個(gè)java進(jìn)程的一些運(yùn)行瓶頸點(diǎn),可以通過該命令找到所有當(dāng)前Thread的占用CPU的時(shí)間,也就是這里的最后一列。
比如這里找到了一個(gè)TID : 30834 ,所占用的TIME時(shí)間最高。
通過 printf “%x\n” 30834 首先轉(zhuǎn)化成16進(jìn)制, 繼續(xù)通過jstack命令dump出當(dāng)前的jvm進(jìn)程的堆棧信息。 通過Grep命令即可以查到對(duì)應(yīng)16進(jìn)制的線程id信息,很快就可以找到對(duì)應(yīng)最耗CPU的代碼快在哪。
簡(jiǎn)單的解釋下,jstack下這一串線程信息內(nèi)容:
Java代碼
“DboServiceProcessor-4-thread-295” daemon prio=10 tid=0x00002aab047a9800 nid=0x7d9b waiting on condition [0x0000000046f66000]
nid : 對(duì)應(yīng)的linux操作系統(tǒng)下的tid,就是前面轉(zhuǎn)化的16進(jìn)制數(shù)字
tid: 這個(gè)應(yīng)該是jvm的jmm內(nèi)存規(guī)范中的唯一地址定位,如果你詳細(xì)分析jvm的一些內(nèi)存數(shù)據(jù)時(shí)用得上,我自己還沒到那種程度,所以先放下
top命令
命令:top -Hp pid
結(jié)果顯示:
和前面的效果一下,你可以實(shí)時(shí)的跟蹤并獲取指定進(jìn)程中最耗cpu的線程。 再用前面的方法提取到對(duì)應(yīng)的線程堆棧信息。
判斷I/O瓶頸
mpstat命令
命令:mpstat -P ALL 1 1000
結(jié)果顯示:
注意一下這里面的%iowait列,CPU等待I/O操作所花費(fèi)的時(shí)間。這個(gè)值持續(xù)很高通??赡苁荌/O瓶頸所導(dǎo)致的。
通過這個(gè)參數(shù)可以比較直觀的看出當(dāng)前的I/O操作是否存在瓶頸