day12_linux

- 日理万妓 2023-06-01 06:12 35阅读 0赞

同步请求：请求发完，服务器返回结果

异步请求：消息先发至a系统，然后a系统再放到消息队列中（kafka/mq）。a再把消息队列中内容给b系统。。。b->c->d->c->b->a。。。最后消息再返回来

压a的话，tps可能很高。a只是告诉消息我已经接收了，但是可能没有处理，只是传给其他系统了。

那么总tps怎么算？  链路的tps=完成的请求数/时间

mock银行中称呼为挡板。

依赖一个第三方的服务，假设依赖支付宝。写一个服务返回需要的东西。中间没任何逻辑处理，只返回你要的东西。

如果我们压b,就需要把后面的cd都给mock掉。这样得出来就是纯b的结果

![1530544-20190623132928276-1898345675.png][]

我们操作系统要讲两天，都是围绕 cpu 内存 磁盘 io 开展。

\-----

top   看cpu

![1530544-20190623133319229-2137376485.png][]

3:53\-----工作了多长时间（没用）

2 users\-----有几个用户（没用）

load avaerage:0.00  0.00  0.00\-----系统的负载，代表过去1分钟，过去5分钟，过去15分钟系统的平均负载

一般负载会跟cpu联系在一起，负载指的是cpu里面正在运行或者是等待运行的进程以及我们等待io及中断不可恢复的进程的数量

由上面可知，这是一个数量的概念，而不是一个百分比的概念。我们这里说的都是逻辑cpu不是物理cpu，现在的cpu都是超线程，假设有2个物理cpu，那么逻辑cpu有4个

其实，就是vmstat命令中r的值。r就是cpu里面正在运行或等待的进程

![1530544-20190623134315650-356532490.png][]

task: 98 total,1 running,97 sleeping,0 stopped,0 zombie  进程的状态，这里的状态不全。running/runable ,中断会有2个状态，一个D一个S

僵尸进程：本应释放空间的没有释放掉

中断不可恢复：例如去磁盘中读数据，这种可以预期的，马上会处理完的。这个状态的时候不可被干扰

D:不可中断睡眠 (通常是在IO操作) 收到信号不唤醒和不可运行, 进程必须等待直到有中断发生

中断可恢复：可以被打断的，比如外部设备的输入，从键盘上读输入的值，这种不可预期的

s:可中断睡眠 (休眠中, 受阻, 在等待某个条件的形成或接受到信号)

列表中的S就是状态

![1530544-20190623134923256-9483489.png][]

vmstat中b对应的就是中断不可恢复的进程。vmstat 1 每隔1s监控一次

![1530544-20190623140037634-161828749.png][]

负载也就是r+b的总和。那么我们不能这么粗暴的说，因为r+b是瞬时的，但是load average是平均值

问题：怎么理解负载？cpu高负载就一定高吗？cpu低负载就一定低吗？负载高cpu就一定高吗？

答：io密集型应用，大量操作io，负载高，大量中断。。。，这时cpu可能就不高

cpu密集型应用，cpu高，负载也高。

假如java占了所有cpu时间片。此时cpu就高，但是负载可能就不高，就他一个进程在

Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st:us--user cpu,sy--system cpu,ni--nice,id--idle,wait--iowait,hi--hardware irq硬中断,si--soft irq软中断,st--如果开启了虚拟机，就是虚拟机中消耗的cpu

us: is meaning of "user CPU time"   用户空间占用CPU百分比
    sy: is meaning of "system CPU time"  内核空间占用CPU百分比
    ni: is meaning of" nice CPU time"  用户进程空间内改变过优先级的进程占用CPU百分比
    id: is meaning of "idle"  空闲CPU百分比
    wa: is meaning of "iowait"   等待输入输出的CPU时间百分比
    hi：is meaning of "hardware irq"  硬件中断
    si : is meaning of "software irq"  软件中断 
    st : is meaning of "steal time"  实时（来源http://bbs.chinaunix.net/thread-1958596-1-1.html）

us:用户态cpu，用户进程所消耗的cpu,下图的root可以理解为用户cpu，但是他也会消耗系统cpu,比如去操作磁盘，用户进程会切换到内核进程去读写磁盘，这个时候就是sy

![1530544-20190623174411267-557918162.png][]

sy:内核态cpu，内核进程消耗的cpu

对于一般应用来说，我们希望是us cpu高，用户自己本身使用占用的时间多

如果tps随着vu增加而下降。那是因为sy消耗占的多了，消耗用户本身的实际减少了。所以，就会出现下降的情况。为什么sy会增加，因为上下文切换

上下文切换：cpu上下文切换的类型，根据任务的不同，可以分为进程上下文切换（进程间上下文切换和进程内部上下文切换\[内部：从用户态切换到内核态\]），线程上下文切换\[多线程\]，中断上下文切换

切换都是在内核里完成的，因此会消耗内核cpu

上文：当前运行的内存地址

下文：回来之后，下个将从哪运行

上下文是指某一时间点 CPU 寄存器和程序计数器的内容。寄存器是 CPU 内部的数量较少但是速度很快的内存（与之对应的是 CPU 外部相对较慢的 RAM 主内存）。寄存器通过对常用值（通常是运算
    的中间值）的快速访问来提高计算机程序运行的速度。程序计数器是一个专用的寄存器，用于表明指令序列中 CPU 正在执行的位置，存的值为正在执行的指令的位置或者下一个将要被执行的指令的位置，
    具体依赖于特定的系统

进程和进程之间消耗cpu一般是最多的,线程消耗cpu最小

中断：比如，运行运行着，要读io了。此时，cpu时间片就跑到下一个进程了

上下文切换都要消耗内核cpu，大量的上下文切换内核cpu就高了。

ni:优先级，优先级高的进程耗费的cpu(值在0～-20之间。-20为最高优先级，默认都是0)，会发生抢占cpu.抢占会发生上下文切换

id:空闲

wa:iowait，等待磁盘所耗费的cpu,一般写操作不会耗费太多cpu

hi:硬件中断

si:软件中断

st:如果开启了虚拟化，在虚拟化里面耗费的cpu，一般是碰不到的

system里面的cs，是中断

![1530544-20190623182658479-449737496.png][]

tomcat写日志耗费的是用户cpu还是系统cpu:

答：系统cpu

为啥是内核cpu，不是用户进程在操作吗？

答：因为在写日志的时候，用户进程是没权限的，需要切换到内核空间，内核去调用系统，底层命令去写日志，所以消耗的是内核cpu

如果tps最大，但是cpu还没打满。要去分析原因。low开发就说加机器，高级高发就尽量发挥硬件资源

cpu到此结束=，我们之前讲的都是逻辑cpu

下面开始讲解内存

![1530544-20190623183748819-1060353743.png][]

Mem:   1028960k total,   271308k used,   757652k free,    15372k buffers:物理内存，真实内存。

Swap:  2064376k total,        0k used,  2064376k free,    88860k cached:虚拟内存，从磁盘虚拟出来的一块内存。现在基本没什么用。很小一部分在内存，大部分都是磁盘上

内存的速度是磁盘的百倍甚至千倍快，所以磁盘真的快的话，那还要内存干嘛。

total:总共  used:已使用  free:剩余  buffers:缓冲(写：把耗时长的需要向内存同步的放到buffer里，会自动往内存同步)  cached: 缓存(读：把磁盘中常用的数据放到cache里)

top之后按数字1，就会出现cpu0 cpu1

竖着的是单个cpu的累加值，有几个cpu，最大就能到几百

上面的cpu(s)  是平均值，最多100%

那究竟多少算高，平均cpu达到80%的时候就算高（us+sy）一起。前提提交他是一个io密集型，我们接触的大部分都是io密集型。很少涉及到cpu密集型，计算多的系统，比如银河计算机

负载什么时候算高？大于cpu的颗粒数就算高。建议是cpu颗粒数的百分之七八十

![1530544-20190624221946139-178775470.png][]

内存怎么看？

java服务：(1)物理内存有没有大于他最大的申请内存    (2)他的gc频率以及gc的时间

非java服务：看物理内存使用率不让超过80%

读磁盘：从磁盘里把数据拿到内存里。

为什么读磁盘？

答：内存中没有需要的数据了，需要到硬盘里读

写磁盘：cpu在内存里干完之后，再写到磁盘里

那么是数据库写快还是数据库读快？

答：写快，因为写到内存就完了，后面是内存自己同步到硬盘里。这就是为啥有的时候写东西一断电数据就没了(比如excel)，因为是在内存里的，在同步到磁盘的时候丢了

看几核cpu,top之后按数字1，有几个就是几个逻辑cpu。或者cat /proc/cpuinfo   processor就是cpu数

![1530544-20190624223831574-922599668.png][]

看磁盘分区：fdisk     fdisk -l

![1530544-20190624225303643-1654814450.png][]

iostat也可以看，device

![1530544-20190624225414580-330049586.png][]

一次io可能包含多次磁盘的读操作，磁盘的写操作。

磁盘的io，就是读写的合并动作

top命令里没有io数据。我们常用的是iostat

tps:磁盘的tps，每秒操作磁盘的次数

blk\_read/s:读速率

blk\_wrtn/s:写速率

blk\_read:目前为止读了多少字节

blk\_wrtn:目前为止写了多少字节

我们平时用的多的还有iostat -x

![1530544-20190624230105581-29260944.png][]

分析用到下面几个就可以了。

avgrq-sz:平均每次操作的数据量是多少

avgqu-sz:磁盘队列长度

await:我每次操作磁盘的平均时间

r\_await:读磁盘的平均时间

w\_await:写磁盘的平均时间

svctm：service time 磁盘真正自己读写耗时的时间(ms)----标准，机械硬盘不超过5ms，如果这里大于5，说明磁盘有问题

%util:

我们一般使用nmon来操作：红框框里那些参数操作一下就好

![1530544-20190624232015408-194084718.png][]

看磁盘，我们就按一下d

busy：繁忙。这是最简单的方式看磁盘烦不烦忙。如果持续超过20%就说明比较忙了

到底是读多还是写多。看后面的read/write就知道了

![1530544-20190624232106531-931486554.png][]

nmon  然后 按n进入网络

上行/下行带宽。说通俗点就是上传和下载

recv=kb/s

trans=kb/s

![1530544-20190624233253847-928959816.png][]

netstat -i也可以看

![1530544-20190624234117848-1421097249.png][]

如果cpu也没满，请求也没超时。那么就一定达到最大值了吗？

答：可能达到最大值，因为cpu还会操作其他的东西，数据库什么。。。。

=================================================================================

今天基本内容就到此为止，下面讲一些常用命令：

linux性能监控分析命令：

top:看的最多的命令

pid:进程号

NI：优先级

VIRT：进程占的内存（虚拟+共享+物理）

RES：物理内存（我们一般看这个就够了）

SHR：共享内存（可能会大于VIRT，大于RES），不光你共享，其他人也可能共享

S：

%CPU：单个cpu颗粒数之和（包括user和sys）

%MEM：

TIME+：

COMMAND：

常用快捷键----------

shift+p:按cpu排序

shift+m:按内存排序

？：查看说明

shift+f：查看其他用法

c:查看路径

![1530544-20190625234256345-81742461.png][]

这个我们默认是看的进程数据，且3s一次。我们可以通过按h来切换进程线程的数据查看

\-p的话，只看这一个进程

top -p 122(pid)

![1530544-20190626194608452-1815080352.png][]

大叔举的银行的一个例子：
    负载机：16c  48g
    服务器：48c  96g
    单负载机：50个并发，tps是100        40%
    50以上并发，tps怎么都上不去      -----到底是服务器还是负载机的瓶颈？（暂时无法确定是发不过去还是处理不过来）
    单负载机：100个并发，tps是60        38%
    3台负载机：150个vu，tps是180       90%    -----这一步证明上一步负载机发不过去，所以要查一下负载机
    问题1:100个并发时tps没有提升反而下降
    问题2:3台负载机100个vu的tps为什么不是200
    
    
    线程还好，进程压的方式，一定要看多台负载机压的情况
    因为只有进程压测，50个并发时，起了50个进程，大于50个进程，反而下降。
    进程之间的争用导致负载机用户态的cpu减少，给用户态干活的cpu时间片减少
    内核态竞争导致的cpu时间片增加，给真正去lr干活的cpu时间减少了

vmstat:

si:网虚拟内存里面写

so:从虚拟哪来

cs:中断和上下文切换一般不要超过10W，超过10W就很高了

![1530544-20190626200104288-445019530.png][]

iostat/iostat -x:

![1530544-20190626202120287-622752684.png][]

uptime:

![1530544-20190626202258889-1725702854.png][]

free:

![1530544-20190626202326184-1821770541.png][]

sar:监控linux最全的命令，有很多参数可选

![1530544-20190626202433214-225029293.png][]

sar -d和iostat -x结果差不多

strace：sy使用高时，看内核调用情况

us比较高，看是那个进程或线程高

如果sy比较高， 我们一般只能定位到应用。我们一般就是判断到中断或上下文切换高。但是我们us可以判断到进程和线程的级别，达到了方法的级别。sy只能定位到进程的级别，但是想知道里面什么方法导致的就很难判断。strace 就是主要跟踪这个进程的内核操作情况

这个命令很难，一般人都不会

lsof:

nmon:进入nmon安装目录下执行，因为没加环境变量

nmon大叔一般不用，作报告的时候用。

最大的用处是可以离线收集操作系统的数据，还可以绘成图

./nmon -fT -s 2 -c 2:

\-s 2:每2秒进行一次数据采集

\-c 2:一共采集两次

输入命令后，将自动在当前目录生产一个hostname\_timeSeries.nmon的文件（hostname为当前监视的服务器的主机名）如：

djt\_137\_188\_130226\_1749.nmon

find / -name *.nmon    通过这个去查找

![1530544-20190626213041148-1007216962.png][]

生成的这个只支持excel，不支持wps:

![1530544-20190626220559792-754019058.png][]

想更直观的看，就用下面这个

![1530544-20190626221720479-462248353.png][]

转载于:https://www.cnblogs.com/Charles2625/p/11072423.html

[1530544-20190623132928276-1898345675.png]: /images/20230601/942d48ce5e9240e381749dd1499135b3.png
[1530544-20190623133319229-2137376485.png]: /images/20230601/e534ecf1462c4ed7a8cf3f9b08b45a57.png
[1530544-20190623134315650-356532490.png]: /images/20230601/6eaf2e984fa14a258939eae168349726.png
[1530544-20190623134923256-9483489.png]: /images/20230601/296423ddf3ea4031986b676ff935ba64.png
[1530544-20190623140037634-161828749.png]: /images/20230601/039e3b0de2e54ef2b507d9aee4ee7080.png
[1530544-20190623174411267-557918162.png]: /images/20230601/2eb690c82d9d467ca6a8d96d9c893013.png
[1530544-20190623182658479-449737496.png]: /images/20230601/0fab5d9762fb4623a3d2e095a8caf20c.png
[1530544-20190623183748819-1060353743.png]: /images/20230601/04cf9291326a42e0a7ebc54db3465e38.png
[1530544-20190624221946139-178775470.png]: /images/20230601/88e81c3eb53444beab7f97a9cc84ebda.png
[1530544-20190624223831574-922599668.png]: /images/20230601/1b263a7c171145648ca4613ca412666e.png
[1530544-20190624225303643-1654814450.png]: /images/20230601/10598e8498164558a8dbc5d70fd98988.png
[1530544-20190624225414580-330049586.png]: /images/20230601/dad9a5a6b87344e7ade25e93cbbdb25f.png
[1530544-20190624230105581-29260944.png]: /images/20230601/71e289d6ab7d4ad3800943284cf9af02.png
[1530544-20190624232015408-194084718.png]: /images/20230601/81247ce92ac84d42ae750399fab844eb.png
[1530544-20190624232106531-931486554.png]: /images/20230601/72394294ed4b4b89b5f89f5144d83d2f.png
[1530544-20190624233253847-928959816.png]: /images/20230601/e82f587da273409b9c8bb361ae215d53.png
[1530544-20190624234117848-1421097249.png]: /images/20230601/caabfe54478b435ab64eb0e9b904a4d1.png
[1530544-20190625234256345-81742461.png]: /images/20230601/fc961db8f5724466a514ea20703148f8.png
[1530544-20190626194608452-1815080352.png]: /images/20230601/bc3f2c3381224716a68b2219f48dd8ea.png
[1530544-20190626200104288-445019530.png]: /images/20230601/3e373581f1174cb09f56eaa7efe518d0.png
[1530544-20190626202120287-622752684.png]: /images/20230601/b93a471e8f494200b14e9dab2ce567d2.png
[1530544-20190626202258889-1725702854.png]: /images/20230601/c627e9546c044cf1b0648a2fe02679e4.png
[1530544-20190626202326184-1821770541.png]: /images/20230601/ad97b9ac3a6c4333b8e489a13276688f.png
[1530544-20190626202433214-225029293.png]: /images/20230601/bf4f93f1958e4f3ab784f31d225d183c.png
[1530544-20190626213041148-1007216962.png]: /images/20230601/2e949806710242c093cd794eb3724d24.png
[1530544-20190626220559792-754019058.png]: /images/20230601/c64624b9eaa1456eb19bf638cc05162c.png
[1530544-20190626221720479-462248353.png]: /images/20230601/0ac66db7e9a848309d9d2b1f53c15a91.png