服务器出现由内存问题引发的故障，例如系统内部服务响应速度变慢、服务器登录不上、系统触发 OOM（Out Of Memory）等。通常情况下当实例内存使用率持续高于90%时，可判断为实例内存使用率过高。CPU/内存使用率过高的问题原因可能由硬件因素、系统进程、业务进程或者木马病毒等因素导致。
笔者以前写过一篇文章- Linux 下的 60 秒分析的检查清单 ，适用于 任何性能问题 的分析工作，这一篇文章是关于CPU/内存使用率的具体的排查思路总结。
执行 top 命令后按 M ，根据驻留内存大小进行排序，查看 “RES” 及 “SHR” 列是否有进程占用内存过高。按 P，以 CPU 占用率大小的顺序排列进程列表，查看是否有进程占用cpu过高。
如果有异常进程占用了大量 CPU 或内存资源，记录需要终止的进程 PID，输入k，再输入需要终止进程的 PID ，按 Enter。
另外说明一下，top 运行中可以通过 top 的内部命令对进程的显示方式进行控制，最常用的是M和P。
CPU 空闲但高负载情况，Load average 是 CPU 负载的评估，其值越高，说明其任务队列越长，处于等待执行的任务越多。执行ps -axjf命令，查看进程状态，并检查是否存在 D 状态进程。D 状态指不可中断的睡眠状态，该状态进程无法被杀死，也无法自行退出。若出现较多 D 状态进程，可通过恢复该进程依赖资源或重启系统进行解决。
Linux 系统通过分页机制管理内存的同时，将磁盘的一部分划出来作为虚拟内存。而 kswapd0 是 Linux 系统虚拟内存管理中负责换页的进程。当系统内存不足时，kswapd0 会频繁的进行换页操作。换页操作非常消耗 CPU 资源，导致该进程持续占用高 CPU 资源。
执行top命令，找到 kswapd0 进程。观察 kswapd0 进程状态，若持续处于非睡眠状态，且运行时间较长并持续占用较高 CPU 资源，执行 vmstat ，free，ps 等指令，查询系统内进程的内存占用情况，重启系统或终止不需要且安全的进程。如果 si，so 的值也比较高，则表示系统存在频繁的换页操作，当前系统的物理内存已经不能满足您的需要。 si 表示每秒从交换区写入内存的大小(单位:kb/s) ， so 每秒从内存写到交换区的大小。
执行cat/proc/meminfo |grep-i shmem命令查看共享内存。
buddy可以以页为单位获取连续的物理内存了，即4K为单位。slab负责需要频繁的获取/释放并不大的连续物理内存，比如几十字节。执行cat /proc/meminfo | grep -i SUnreclaim命令查看slab 内存。
标准的 4KB 大小的页面外，内存大页管理内存中的巨大的页面，处理较少的页面映射表，从而减少访问/维护它们的开销。执行cat /proc/meminfo | grep -iE "HugePages_Total|Hugepagesize" 查看内存大页。
内存使用率计算：
(Total - available)100% / Total
（Total - Free - Buffers - Cached - SReclaimable + Shmem）* 100% / Total
cat /proc/meminfo查看信息含义：
㈡ 如何查看Linux 服务器的负载信息
方法一：
通过top命令来查看服务器负载
再对此Linux服务器性能分析之前，先了解下Linux系统Load average负载的知识，负载均值在 uptime 或者top 命令中可以看到
方法二：输入 iostat -x -k -t
说明：%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。
即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
方法三：
如果玩游戏很卡，可以用hdparm –t /dev/磁盘名称来测试磁盘性能是否达标
说明：sd表示硬盘是SATA，SCSI或者SAS，a表示串口的第一块硬盘
㈢ 在linux 中使用uptime 所看到的负载数怎么判断负载高
uptime gives a one line display of the following information. The current time, how long the system has been running, how many users are currently logged
on, and the system load averages for the past 1, 5, and 15 minutes.
uptime会打印出过去1/5/15 分钟的负载，负载值越大负载越高。
如果只有一个CPU，负载为1代表CPU为100%
㈣ 如何查看linux服务器负载
做压力测试的时候想看看Linux服务器当前负载如何，性能怎样，可以使用下面这些命令
uptime
显示当前用户数，以及最近1
分钟内、5分钟内、15
分钟内系统的平均负载
cat
/proc/loadavg
用于显示系统1秒钟平均负载、5秒钟平均负载、15秒钟平均负载、总作业数、正在运行的作业总数
cat
/proc/stat
这个显示的内容较多，具体的就不一一列举了，需要的朋友可以自己查阅相关资料
㈤ Linux里面iptables怎么实现负载均衡
1. iptables实现负载均衡的方式：
在Linux中使用iptables完成tcp的负载均衡有两种模式：随机、轮询
The statistic mole support two different modes:
random:(随机)
the rule is skipped based on a probability
nth:（轮询）
the rule is skipped based on a round robin algorithm
2. example
㈥ linux服务器的平均负载问题
如果可以抄进入linux系统的话，袭用top查看系统的负载，
我们可以通过load avg来分析当前cpu的使用情况。
比如1颗cpu 在load avg里代表一个1.00 2颗cpu那么他的负载就不应该长时间保持在2.00
你可以再top里按1查看每颗cpu的使用情况
按照你上述的情况。如果WDCP面板里显示的是4个核心，那么他的load avg长时间保持在3.00-4.00之间就应该属于高负载了。
㈦ Linux 平均负载
1、查看Linux系统CPU个数
2、每次发现系统变慢时，我们通常做的第一件事，就是执行top或者uptime命令
2.1、如果1分钟、5分钟、15分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。
2.2、但如果1分钟的值远小于15 分钟的值，就说明系统最近1分钟的负载在减少，而过去15分钟内却有很大的负载。
2.3、反过来，如果1分钟的值远大于 15 分钟的值，就说明最近1分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦1分钟的平均负载接近或超过了CPU的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。
eg：假设我们在一个单 CPU 系统上看到平均负载为 1.73，0.60，7.98，那么说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低。
2.4、当平均负载高于 CPU 数量70%的时候，你就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。
2.5、CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应
2.5.1、CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
2.5.2、I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
2.5.3、大量等待 CPU 的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高。
3、使用工具iostat（stress）、mpstat、pidstat 等工具，找出平均负载升高的根源
3.1、stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景
3.2、而 sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。
3.2.1、mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有CPU的平均指标。
3.2.2、pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标
首先，在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景
接着，在第二个终端运行uptime查看平均负载的变化情况
最后，在第三个终端运行mpstat查看 CPU 使用率的变化情况
那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询
首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync
还是在第二个终端运行uptime查看平均负载的变化情况
然后，第三个终端运行mpstat查看 CPU 使用率的变化情况
那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询
当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。比如，我们还是使用 stress，但这次模拟的是 4 个进程
由于系统只有 1 个CPU，明显比 4 个进程要少得多，因而，系统的 CPU 处于严重过载状态，平均负载高达3.71
接着再运行pidstat来看一下进程的情况
㈧ 如何理解Linux下的负载均衡
我空间里面有
㈨ linux服务器的平均负载问题
如果是web服务器，用到程序与数据库交互的服务器，您报出的硬件配置，负载6以内可以稳定运行，负载12以内可以正常运行，负载高于15运行吃力，负载18以上明显感觉变慢，更高可能就运行出错了。我指的是一般情况下。
如果是特殊情况，内部机制导致的服务宕机假死，那么负载值的呈现可能不高的，但是有问题的服务已经不能正常工作了，需要重启这个服务，一旦重启这个假死的服务进程，系统负载就会立刻随之升高，因为可能随着重启这个服务进程之后，服务突然能响应了堆积的并发请求，导致突发性升高，然后可能迅速降低负载。 所以负载是表示系统的综合运行载荷，不完全是cpu的占用率。 在linux系统里，几种情况都可以导致负载高：1.系统进程占用时间过长 2.应用程序的进程占用cpu时间过长 3.磁盘读写I/O的进程占用cpu的时间过长。 是否稳定运行，不能单单以负载值作为评估标准，只能作为大概的参考。负载高的原因要从我之前说的3个原因方面去查，查到了问题后，就可以改进改善，从而实现稳定运行。
其实有很多特例的，据我所知，某些大型的知名网站服务器原来采用lamp架构的，在负载100以上都能正常运行，这么高的负载其实在某些情况下特别是大规模并发情况下，只要把控好软硬件的协作关系，照样可以正常运作。
我从事linux网站运维数年了，希望我的回答你能满意。
㈩ Linux的负载均衡详解
Linux的负载均衡常用的有三种技术：中国人搞出来的大神级产品 LVS Linux Virtual Server，俄罗斯的Nginx，来发法国的HAProxy。都是基于Linux的开源免费的负载均衡软件。
1. 抗负载能力强，性能高，能达到F5的60%，对内存和CPU资源消耗比较低
2. 工作在网络4层，通过VRRP协议(仅作代理之用)，具体的流量是由linux内核来处理，因此没有流量的产生。
3. 稳定，可靠性高，自身有完美的热备方案(Keepalived+lvs)
4. 不支持正则处理，不能做动静分离。
5. 支持多种负载均衡算法：rr(轮询)，wrr(带权轮询)、lc(最小连接)、wlc(带权最小连接)
6. 配置相对复杂，对网络依赖比较大，稳定性很高。
7. LVS工作模式有4种：
(1) nat 地址转换
(2) dr 直接路由
(3) tun 隧道
(4) full-nat
1. 工作在网络7层，可以针对http应用做一些分流的策略，比如针对域名，目录结构
2. Nginx对网络的依赖较小，理论上能ping通就能进行负载功能
3. Nginx安装配置比较简单，测试起来很方便
4. 也可以承担较高的负载压力且稳定，nginx是为解决c10k问题而诞生的
5. 对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测
6. Nginx对请求的异步处理可以帮助节点服务器减轻负载压力
7. Nginx仅能支持http、https和Email协议，这样就在适用范围较小。
8. 不支持Session的直接保持，但能通过ip_hash来解决。对Big request header的支持不是很好。
9. Nginx还能做Web服务器即Cache功能。
1.支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；
2.能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作
3.支持url检测后端的服务器出问题的检测会有很好的帮助。
4.更多的负载均衡策略比如：动态加权轮循(DynamicRoundRobin)，加权源地址哈希(Weighted SourceHash)，加权URL哈希和加权参数哈希(WeightedParameterHash)已经实现
5.单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
6.HAProxy可以对Mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。
7.支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）
8.不能做Web服务器即Cache。
1. 负载能力
lvs抗负载能力最强，因为仅作分发不处理请求，相当于只作转发不做进一步处理直接在内核中完成，对系统资源消耗低（LVS DR模式）；
nginx和haproxy相对来说会弱，但是日PV2000万也没什么问题，因为不仅接受客户端请求，还与后端upstream节点进行请求并获取响应，再把响应返回给客户端，对系统资源和网络资源消耗高；
注：建议如果公司网站流量日PV在2000万以上，并发在7，8万以上才考虑用lvs+keepalived架构
2. 功能性
lvs仅支持4层tcp负载均衡，haproxy可以支持4层tcp和7层http负载均衡，nginx可以支持7层http负载均衡（新版本也支持7层负载均衡）；
nginx功能强大，配置灵活，可做web静态站点，静态缓存加速，动静分离，并支持域名，正则表达式，Location匹配，rewrite跳转，配置简单直观明了，还可以结合etc或consule做发布自动化上下线等等；
haproxy相对nginx的7层负载均衡会弱一些，灵活性不足，个人建议一般用haproxy做TCP负载均衡更合适一些；
3. 运维复杂度
lvs相对来说部署架构更复杂一些，lvs对网络是有要求，lvs必须与real server在同一个网段，也更费资源，需要多2台服务器成本；
nginx和haproxy部署架构更简单，对网络也没要求，更便于后续维护；
像对于大型的，需要进行高并发的网站或者对网络不太严格的时候，可以使用nginx；
对于大型的Web服务器的时候可以使用haproxy；
对性能有严格要求的时候可以使用lvs，就单纯从负载均衡的角度来说，lvs也许会成为主流，更适合现在大型的互联网公司。
注：lvs,nginx,haproxy要实现高可用，都需要借助keepalived软件