目录
前言
此篇文章来源于公众号:linux就该怎么学
1、cpu告警
通过top命令,查看所有进程运行情况,在结果界面,通过shift+p界面切换视图,按照cpu使用率倒序排序,找出cpu使用率最高的进程一次分析(查看%cpul列)
top命令显示的cpu使用率的按照单核计算,即100S%代表使用单核的满负荷,通过服务器是4核cpu,那么理论上最大为400%
[root@localhost ~]# top
Tasks: 197 total, 1 running, 196 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.2 us, 1.3 sy, 0.0 ni, 97.3 id, 0.2 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 8008984 total, 1046216 free, 4712336 used, 2250432 buff/cache
KiB Swap: 7208956 total, 4409068 free, 2799888 used. 2373196 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1456 root 20 0 10.5g 361648 242164 S 3.0 4.5 12461:08 clickhouse-server --config-file=/etc/clickhouse-+
1089 root 20 0 5755452 238580 2644 S 1.7 3.0 4330:47 java -jar V2XRealtimeServer.jar
1086 root 20 0 5822324 319628 3028 S 1.3 4.0 4161:58 java -jar V2XRawDataServer.jar
10174 root 20 0 5819584 963512 4420 S 1.3 12.0 3619:07 java -jar V2XWebSocketServer.jar
2105 mysql 20 0 3205688 907124 7584 S 0.7 11.3 1462:50 /usr/sbin/mysqld --daemonize --pid-file=/var/run+
1090 root 20 0 148952 4648 780 S 0.3 0.1 420:01.32 /usr/local/redis/bin/redis-server 0.0.0.0:7379 [+
17013 root 20 0 162128 2344 1600 R 0.3 0.0 0:00.04 top
1 root 20 0 125516 2636 1492 S 0.0 0.0 133:31.76 /usr/lib/systemd/systemd --switched-root --syste+
1)根据不同进程,可能会存在的现象
a、cpu持续报警,一般为计算机行应用程序,如数据清洗,转换、计算等,即该应用程序运行时本就会使用更多的CPU资源。
b、偶然报警。只要告警不超过cpu总资源的70%,不引起系统卡顿,原则上可暂时不用处理
c、偶然报警,但是告警频率逐渐增高,可能是由于应用程序bug,漏洞引起
d、特定时间告警,一般与业务关联性高有关,比如流量高峰。
2) 处理方案
a、根据实际业务需要,可以限制单应用的运行性能(如集群部署,可以适当的降低节点的当店性能),调整相关配置,限制线程数,并发量等。
b、如果公共组件该版本有相关漏洞缺陷,则根据官网文档指示,修补漏洞,或者升级版本
c、解决业务流量高的问题,使流量更均衡,如集群部署,消息缓存,负载均衡,定时任务调整。
d、扩容服务器资源。如增加cpu资源,或者将应用服务迁移到资源性能更高的服务器。
2、内存告警
通过top命令。查看所有进程运行情况,在结果界面,通过shift+M切换视图,按照内存使用量倒序排序,找出内存使用量最高的进程依次分析(查看RES和%MEM列)
[root@localhost ~]# top
Tasks: 195 total, 1 running, 194 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.3 us, 1.1 sy, 0.0 ni, 97.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8008984 total, 969272 free, 4721960 used, 2317752 buff/cache
KiB Swap: 7208956 total, 4409068 free, 2799888 used. 2363556 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10174 root 20 0 5819584 963512 4420 S 1.3 12.0 3619:52 java -jar V2XWebSocketServer.jar
10166 root 20 0 5768092 921932 4252 S 0.0 11.5 364:51.16 java -jar V2XStatisticsServer.jar
2105 mysql 20 0 3205688 907124 7584 S 0.0 11.3 1463:03 /usr/sbin/mysqld --daemonize --pid-file=/var/run+
1087 root 20 0 5809328 449920 2736 S 0.0 5.6 226:25.74 java -jar V2XApiServer.jar
1456 root 20 0 10.5g 369520 242164 S 3.0 4.6 12463:01 clickhouse-server --config-file=/etc/clickhouse-+
1086 root 20 0 5822324 319628 3028 S 1.3 4.0 4162:45 java -jar V2XRawDataServer.jar
1064 root 20 0 5702928 286440 2272 S 0.3 3.6 721:06.60 java -jar msbus.jar
1089 root 20 0 5755452 238580 2644 S 1.7 3.0 4331:30 java -jar V2XRealtimeServer.jar
27891 root 20 0 1111052 25192 2324 S 0.0 0.3 4:21.71 /usr/bin/dockerd -H fd:// --containerd=/run/cont+
1)常用处理方案
a、调整应用服务相关参数,限制内存占用,缓存空间大小,缓存队列长度,缓存保留时间,内存管理参数
b、扩容服务器内存资源,或将应用服务迁移到高性能服务器
3、磁盘空间告警
通过df -h 命令,查看磁盘各分区占用量,(查看Use%和Mounted on列),然后使用du -sh 命令逐级查找分区内磁盘使用量最高的目录。
[root@ecs-fb36-0002 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 16G 0 16G 0% /dev
tmpfs 16G 832K 16G 1% /dev/shm
tmpfs 16G 1.7G 14G 11% /run
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/mapper/klas_host--10--169--183--49-root 95G 9.6G 86G 11% /
tmpfs 16G 3.5M 16G 1% /tmp
/dev/vda2 1014M 217M 798M 22% /boot
/dev/vda1 200M 5.8M 195M 3% /boot/efi
/dev/mapper/vgdata-lvdata 100G 56G 45G 56% /data
tmpfs 3.1G 0 3.1G 0% /run/user/993
tmpfs 3.1G 0 3.1G 0% /run/user/1000
#分析 /data 目录,然后继续分析 /data/jnpf 目录
[root@ecs-fb36-0002 ~]# du -sh /data/*
4.6M /data/h5
40M /data/ioc-guanai
242M /data/jdk
54G /data/jnpf
5.2M /data/redis
952M /data/soft
1)常用解决方案
a、占用磁盘高的为日志文件,crontab+logrotae
b、数据盘磁盘占用高(独立挂载磁盘的分区。如/data),包括安装程序,数据文件等,根据实际业务场景,调整相关参数,限制数据保存时间,数据压缩等。
c、系统盘磁盘占用高(/根分区),则考虑将相关应用程序迁移到数据盘,如果应用程序支持,可以将安装目录整体迁移(如修改docker镜像存储目录,减轻系统盘负担,即配置数据盘后,将将现有数据迁移到数据盘 重启服务)
d、扩容服务器磁盘资源,而且只能扩容数据盘,或者增加独立挂载磁盘,然后将相关业务迁移搭配新磁盘
4、磁盘IO 告警
使用iotop命令(需要独立安装),查看磁盘IO 最高的进程,其中SWAPIN列为swap交换百分比,IO>列为IO等待所占用百分比
[root@localhost ~]# iotop -o
Total DISK READ : 0.00 B/s | Total DISK WRITE : 388.00 K/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 633.68 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
518 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.16 % [xfsaild/dm-0]
20271 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/3:2]
2178 be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % java -jar V2XRawDataServer.jar
2229 be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % java -jar V2XRawDataServer.jar
2286 be/4 root 0.00 B/s 30.61 K/s 0.00 % 0.00 % java -jar msbus.jar
1801 be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % clickhouse-server --config-f~khouse-server.pid [BgSchPool]
23520 be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % clickhouse-server --config-f~khouse-server.pid [Collector]
1253 be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % java -jar V2XRealtimeServer.jar
1254 be/4 root 0.00 B/s 814.17 B/s 0.00 % 0.00 % java -jar msbus.jar
10253 be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % java -jar V2XStatisticsServer.jar
1698 be/4 root 0.00 B/s 142.72 K/s 0.00 % 0.00 % clickhouse-server --config-f~khouse-server.pid [Formatter]
1700 be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % clickhouse-server --config-f~khouse-server.pid [BgSchPool]
1)可能存在的现象
a、cpu持续报警,一般为计算机行应用程序,如数据清洗,转换、计算等,即该应用程序运行时本就会使用更多的CPU资源。
b、偶然报警。只要告警不超过cpu总资源的70%,不引起系统卡顿,原则上可暂时不用处理
c、偶然报警,但是告警频率逐渐增高,可能是由于应用程序bug,漏洞引起
d、特定时间告警,一般与业务关联性高有关,比如流量高峰。
2)常用处理方案
a、根据实际业务需要,可以限制单应用的运行性能(如集群部署,可以适当的降低节点的当店性能),调整相关配置,限制线程数,并发量等。
b、如果公共组件该版本有相关漏洞缺陷,则根据官网文档指示,修补漏洞,或者升级版本
c、解决业务流量高的问题,使流量更均衡,如集群部署,消息缓存,负载均衡,定时任务调整。
d、扩容服务器资源。如使用SSD磁盘,或者将应用服务迁移到资源性能更高的服务器。
5、TCP连接告警
通过netstat命令,查看和统计不同状态的tcp连接数量,以及相应的应用程序。
tcp连接状态告警,一般为两种:ESTABLISHED(已连接状态),TIME_WAIT(自动关闭端的最后状态,等待操作系统回收,其中主动关闭可以是服务端,已可以是客户端 )
a、ESTABLISHED,不管是服务器端应用程序还是客户端应用程序,该状态的tcp连接过多,锁门该应用读物的业务量已经不在单体服务可以处理的,所有需要扩展应用服务
b、TIME_WAIT,服务端应用程序和客户端应用陈旭都可能会出现,而且这是TCP连接的最后一个状态,接下来只有等待操作系统的回收(回收周期更具不同操作系统,可能为30秒-2分钟),但是,在被回收前,该连接还是依然会占用操作系统一个套接字的资源 ,如果短时间出现过多TIME_WAIT,可能是因为高并发且持续的短连接业务场景,最终可能会逐步将操作系统的套接字资源耗尽,从而无法再创建新的TCP连接。
1)常用解决方案
a、ESTABLISHED,服务器端的应用程序,考虑多节点部署,搭建汲取或搭建负载均衡
b、ESTABLISHED,客户端的应用程序,可以考虑使用连接池,避免所有请求都建立新的新的连接。也可以考虑多节点部署客户端。
c、TIME_WAIT,可以考虑使用tcp长连接,如果是htpp服务器出现告警,可以考虑在客户端连接时将connection设置为keep-alive,避免服务端主动断开连接;也可以从操作系统层调整相关参数,一方面开启套接字复用,一方面使得操作系统更快的回收,调整方案如下:
#vim /etc/sysctl.conf,增加或修改以下参数
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_fin_timeout=30
#调整后刷新生效
sysctl -p
2)补充:tcp相关命令
a、使用netstat统计不同的状态的tcp连接数量
特别关注:脚本中NR>2由于netstat命令前2行输出为描述信息
[root@localhost ~]# netstat -antp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:33071 0.0.0.0:* LISTEN 2105/mysqld
tcp 0 0 0.0.0.0:7379 0.0.0.0:* LISTEN 1090/redis-server 0
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1244/sshd
[root@localhost ~]# netstat -antp | awk -F '[ /]+' 'NR>2 {count[$6]++} END {for(state in count) print state,"\t\t",count[state] }'
LISTEN 16
CLOSE_WAIT 2
ESTABLISHED 273
FIN_WAIT2 1
TIME_WAIT 1
b、使用netstat统计指定状态的tcp连接不同进程的数量
[root@localhost ~]# netstat -antp | grep -i established | awk -F '[ /]+' '{count[$8]++} END {for(app in count) print app,"\t\t",count[app] }'
java 124
mysqld 109
clickhouse-ser 6
sshd: 1
redis-server 31