ps -ef | grep tomcat
查看tomcat进程号,以及启动tomcat时所用的java版本
top查看服务器资源
topload average:三个数字分别表示最近 1 分钟,5 分钟和 15 分钟的负责,数值越大负载越重,一般要求不超过核数。
VIRT:virtual memory usage,进程占用的虚拟内存大小。
RES:resident memory usage,进程常驻内存大小,也就是实际内存占用情况,一般我们看进程占用了多少内存,就是看的这个值。
SHR:shared memory,共享内存大小,不常用。
- us 用户空间占用 CPU 时间比例
- sy 系统占用 CPU 时间比例
- ni 用户空间改变过优先级的进程占用 CPU 时间比例
- id CPU 空闲时间比
- wa IO等待时间比(IO等待高时,可能是磁盘性能有问题了)
- hi 硬件中断
- si 软件中断
- st steal time
ps:在top没命令模式下,按1查看每个cpu每个核心运行情况,P:按CPU使用率从高到底排序输出,M:按内存占用从高到底排序输出(或者按“F”,再选择需要排序的字段,按下s确认即可)
top -Hp pid
查看指定进程下的线程信息
printf '%x\n' pid
将pid转换为16进制
jps
列出本机所有java进程的PID
jstack -l pid > stack
保存java的堆栈信息到文件。检查非空闲状态的线程,如果大量线程都停留在同一个位置,那么很可能这个位置就是程序的瓶颈
jstat -gcutil -h3 pid 1000
每1000ms打印一次gc信息,每3行输出一次表头
jmap -heap pid
显示堆内存信息
jmap -histo pid
显示对象内存信息
jmap -dump:live,format=b,file=heapdump.phrof pid
将dump信息保存成文件,可以通过visualVM或者MAT工具分析该文件,找出占用大量内存的对象。如果jvm内存被迅速占满并引起大量full gc,检查是否有某个地方一次性加载了大量的对象到内存中,比如一次性读取数据库表中所有的数据,又或者从网络上接收数据包很大(几百kb的数据包,并发时也可能达到上百兆)
查看网络状态
sar -n TCP 1(查看tcp统计信息,每秒打印一次)
TCPactive/s:新的 TCP 主动连接(也就是 socket 中的 connect() 事件),单位是:连接数/s。
passive/s:新的 TCP 被动连接(也就是 socket 中的 listen() 事件)。
iseg/s:接收的段(传输层以段为传输单位),单位是:段/s
oseg/s:发送的段。
sar -n DEV 1(查看网络接口统计信息,每秒打印一次)
网络接口统计信息rxpck/s / txpck/s:网卡接收/发送的数据包,单位是:数据包/s。
rxkB/s / txkB/s:网卡接收/发送的千字节,单位是:千字节/s。
rxcmp/s / txcmp/s:网卡每秒接受/发送的压缩数据包,单位是:数据包/s。
rxmcst/s:每秒接收的多播数据包,单位是:数据包/s。
netstat -tulnp(列出所有 tcp与udp 端口)
Proto:协议名(tcp协议还是udp协议)
recv-Q:网络接收队列
表示收到的数据已经在本地接收缓冲,但是还有多少没有被进程取走,recv()
send-Q:网路发送队列
对方没有收到的数据或者说没有Ack的,还是本地缓冲区.
这两个值通常应该为0,如果不为0可能是有问题的。packets在两个队列里都不应该有堆积状态。可接受短暂的非0情况。
Local Address:监听的本地地址,0.0.0.0表示监听所有本地地址。
Foreign Address:监听的外部地址
抓包
tcpdump -i eth0 'dst host 192.168.2.111' -w luo.pcap
抓取所有经过网卡eth0到目标地址的包
tcpdump -i eth0 'src host 192.168.2.111' -w luo.pcap
抓取所有来自目标主机的包
tcpdump -i eth0 'host 192.168.2.111' -w luo.pcap
抓取所有和目标主机通信的包信息
查看连接状态
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
CLOSED:表示初始状态
LISTEN:表示服务器端的某个SOCKET处于监听状态,可以接受连接了
SYN_RCVD: 这个状态表示接受到了SYN报文
SYN_SENT:表示客户端已发送SYN报文
ESTABLISHED:表示连接已经建立了
FIN_WAIT_1:表示等待对方的FIN报文(当SOCKET在ESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN报文,此时该SOCKET即进入到FIN_WAIT_1状态)
FIN_WAIT_2:表示半连接,也即有一方要求close连接,但另外还告诉对方,我暂时还有点数据需要传送给你,稍后再关闭连接
TIME_WAIT: 表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了
CLOSING: 表示双方都正在关闭SOCKET连接
CLOSE_WAIT: 表示在等待关闭
LAST_ACK:它是被动关闭一方在发送FIN报文后,最后等待对方的ACK报文。当收到ACK报文后,也即可以进入到CLOSED可用状态了
time_wait状态产生的原因,危害,如何避免
查看CPU信息
lscpu(查看cpu基本信息)
cpuArchitecture: #架构
CPU(s): #逻辑cpu颗数
Thread(s) per core: #每个核心线程
Core(s) per socket: #每个cpu插槽核数/每颗物理cpu核数
socket(s): #cpu插槽数
Vendor ID: #cpu厂商ID
CPU family: #cpu系列
Model: #型号
Stepping: #步进
CPU MHz: #cpu主频
Virtualization: #cpu支持的虚拟化技术
L1d cache: #一级缓存(表示cpu的L1数据缓存)
L1i cache: #一级缓存(L1指令缓存)
L2 cache: #二级缓存
cat /proc/cpuinfo(查看cpu基本信息,具体到每一个核)
mpstat 2 5(查看cpu当前运行的状况,每两秒更新一次,一共更新5次)
%user 在internal时间段里,用户态的CPU时间(%),不包含nice值为负进程 (usr/total)100
%nice 在internal时间段里,nice值为负进程的CPU时间(%) (nice/total)100
%sys 在internal时间段里,内核时间(%) (system/total)100
%iowait 在internal时间段里,硬盘IO等待时间(%) (iowait/total)100
%irq 在internal时间段里,硬中断时间(%) (irq/total)100
%soft 在internal时间段里,软中断时间(%) (softirq/total)100
%idle 在internal时间段里,CPU除去等待磁盘IO操作外的因为任何原因而空闲的时间闲置时间(%) (idle/total)*100
vmstat 1 (查看cpu,内存,io信息)
vmstatr 值:表示在 CPU 运行队列中等待的进程数,如果这个值很大,表示很多进程在排队等待执行,CPU 压力大。
in 和 cs 值:表示中断次数和上下文切换次数,这两个值越大,表示系统在进行大量的进程(或线程)切换。切换的开销是非常大的,这时候应该减少系统进程(或线程)数。
us、sy、id、wa 值:和top的指标一致。
b ,bi 和 bo 值:b值表示因为 IO 阻塞排队的任务数。bi 和 bo 值表示每秒读写磁盘的块数,bi(block in)是写磁盘,bo(block out)是读磁盘。一般这几个值偏大,都意味着系统 IO 的消耗较大,对于读请求较大的服务器,b、bo、wa 的值偏大,而写请求较大的服务器,b、bi、wa 的值偏大。
wa 值:表示因为 IO 等待(wait)而消耗的 CPU 比例。
dstat (查看cpu,磁盘io,网络发包,换页,系统统计)
dstat内存分析
cat /proc/meminfo(查看内存基本信息)
free -m (查看剩余内存)
锁竞争
pidstat -w -p pid(查看上下文切换次数)
cswch:是指进程无法获取所需资源,导致的上下文切换。比如说, I/O、内存等系统资源不足时,就会发生自愿上下文切换。
nvcswch:则是指进程由于时间片已到等原因,被系统强制调度,进而发生的上下文切换。比如说,大量进程都在争抢 CPU时,就容易发生非自愿上下文切换。
如果系统的上下文切换次数比较稳定,那么从数百到一万以内,都应该算是正常的。但当上下文切换次数超过一万次,或者切换次数出现数量级的增长时,就很可能已经出现了性能问题。
磁盘分析
fdisk (查看磁盘基本信息)
df -h(查看磁盘使用情况)
iostat -c(查看部分cpu使用情况)
iostat-c%iowait:表示 CPU 等待 IO 完成时间的百分比
%idle:CPU 空闲时间百分比
如果 %iowait 较高,则表明磁盘存在 IO 瓶颈,如果 %idle 较高,则 CPU 比较空闲,如果两个值都比较高,则有可能 CPU 在等待分配内存,瓶颈在内存,此时应该加大内存,如果 %idle 较低,则此时瓶颈在 CPU,应该增加 CPU 资源。
iostat -d -k -x(查看磁盘使用情况,主要显示IOPS和吞吐量信息)
iostat -d -ktps:设备每秒的传输次数(transfers per second),也就是读写次数。
kB_read/s 和 kB_wrtn/s:每秒读写磁盘的数据量。
kB_read 和 kB_wrtn:读取磁盘的数据总量。
iostat -x(查看磁盘详细信息)
iostat -xrrqm/s 和 wrqm/s:分别每秒进行合并的读操作数和写操作数,这是什么意思呢,合并就是说把多次 IO 请求合并成少量的几次,这样可以减小 IO 开销,buffer 存在的意义就是为了解决这个问题的。
r/s 和 w/s:每秒磁盘读写的次数。这两个值相加就是 tps。
rkB/s 和 wkB/s:每秒磁盘读写的数据量
avgrq-sz:平均每次读写磁盘扇区的大小。
avgqu-sze:平均 IO 队列长度。队列长度越短越好。
await:平均每次磁盘读写的等待时间(ms)。
svctm:平均每次磁盘读写的服务时间(ms)。
%util:一秒钟有百分之多少的时间用于磁盘读写操作。
TIME_WAIT问题解决
查看端口范围
sysctl -a | grep net.ipv4.ip_local_port_range
修改端口范围
vi /etc/sysctl.conf
net.ipv4.ip_local_port_range = 10000 65000
sysctl -p 让修改生效
最小值必须大于等于1024,最大值必须小于等于65535
允许TCP连接重复使用TIME_WAIT状态的句柄/端口
查看:sysctl -a | grep net.ipv4.tcp_tw_reuse
修改:echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
注意,客户端服务端必须同时打开tcp_timestamps(默认打开)
sysctl -w net.ipv4.tcp_fin_timeout=3 (这个修改可能没什么效果)
转载自:
https://mp.weixin.qq.com/s?__biz=MzI1OTY2MzMxOQ==&mid=2247484103&idx=1&sn=d437fd54bac8ac00522aa4538ca9c7a1&chksm=ea74367fdd03bf699d603f39836bb35c0e6190f6781e0eda104a3710705034293255e85bd6b4&scene=21#wechat_redirect
https://mp.weixin.qq.com/s?__biz=MzI1OTY2MzMxOQ==&mid=2247484295&idx=1&sn=cd82eba9d73f816210b2a99f29b85040&chksm=ea74373fdd03be2942ebeffeebebf52f229f0cb7b724e406ff79d050d67db70584c6efbcde85&scene=21#wechat_redirect
https://mp.weixin.qq.com/s?__biz=MzI1OTY2MzMxOQ==&mid=2247484192&idx=1&sn=ea9aa805a5c0ac1e0b55e5477c79d66d&chksm=ea743798dd03be8e4e07bd8e173fa7e447b13cbd0cdcc287ae917b6b99d616bce801450ac22b&scene=21#wechat_redirect
https://mp.weixin.qq.com/s?__biz=MzI1OTY2MzMxOQ==&mid=2247484208&idx=1&sn=b1429f0f07d69a44248cc78d3942c5c9&chksm=ea743788dd03be9e88e41df3966eb0ac8250b1741b83b19ab97e5a0980444241d17de6bbba66&scene=21#wechat_redirect
https://cloud.tencent.com/developer/article/1432483
网友评论