系统负载(System Load):系统CPU繁忙程度的度量,即有多少进程在等待被CPU调度。
平均负载(Load Average):一段时间内系统的平均负载,这个一段时间一般取1分钟、5分钟、15分钟。
可以使用top或w命令进行查看
系统的最大负载一般受一下因素影响:
1.带宽
一个系统的带宽首先就决定了这个系统的负载能力,其单位为Mbps。
2.硬件配置
CPU频率和核数、内存大小以及速度、硬盘速度等硬件指标决定了一个系统的最大负载能力,也是上限。
3.系统配置
系统最大打开文件描述符数、进程最大打开文件描述符数、单个用户能够打开的最大进程数、系统最大线程数、线程栈大小、TCP内核参数都会影响系统负载。
4.应用服务器配置
Ngixn是目前使用最广泛的反向代理软件,其worker数目、keepalive timout、worker_rlimit_nofile、upstream等配置也会影响系统负载。
MySQL、Redis的性能也会影响系统负载。
5.程序逻辑
对于一个系统,20%的功能会带来80%的流量。这就是28原则的意思,当然也是我自己的一种表述。因此在设计系统的时候,对于80%的功能,其面对的请求压力是很小的,是没有必要进行过度设计的。但是对于另外20%的功能则是需要设计再设计、reivew再review,能够做负载均衡就做负载均衡,能够缓存就缓存,能够做分布式就分布式,能够把流程拆开异步化就异步化。
6.系统架构
负载均衡在服务端领域中是一个很关键的技术。可以分为硬件负载均衡、软件负载均衡。
软件负载均衡中又可以分为四层负载均衡和七层负载均衡。 上文在应用服务器配置部分讲了nginx的反向代理功能即七层的一种成熟解决方案,主要针对的是七层http协议(虽然最新的发布版本已经支持四层负载均衡)。对于四层负载均衡,目前应用最广泛的是lvs,本质上是基于iptables实现的。
实例:
问:如何定位是哪个服务进程导致CPU过载,哪个线程导致CPU过载,哪段代码导致CPU过载?
步骤一、找到最耗CPU的进程
工具:top
方法:
-
执行top -c ,显示进程运行信息列表
-
键入P (大写p),进程按照CPU使用率排序
图示:
如上图,最耗CPU的进程PID为10765
步骤二:找到最耗CPU的线程
工具:top
方法:
-
top -Hp 10765 ,显示一个进程的线程运行信息列表
-
键入P (大写p),线程按照CPU使用率排序
图示:
如上图,进程10765内,最耗CPU的线程PID为10804
步骤三:将线程PID转化为16进制
工具:printf
方法:printf “%x” 10804
图示:
如上图,10804对应的16进制是0x2a34,当然,这一步可以用计算器。
之所以要转化为16进制,是因为堆栈里,线程id是用16进制表示的。
步骤四:查看堆栈,找到线程在干嘛
工具:pstack/jstack/grep
方法:jstack 10765 | grep ‘0x2a34’ -C5 --color
-
打印进程堆栈
-
通过线程id,过滤得到线程堆栈
图示:
如上图,找到了耗CPU高的线程对应的线程名称“AsyncLogger-1”,以及看到了该线程正在执行代码的堆栈。