系统负载（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”，以及看到了该线程正在执行代码的堆栈。