Linux 操作系统状态查看及调优

本是古典何须时尚 2022-08-29 15:48 317阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70][]

*   查看 Memory 运行状态相关工具
 *   查看 IO 运行状态相关工具
 *   查看 Network 运行状态相关工具
 *   查看系统整体运行状态

*  # 系统调优思路 #
 *  # 性能优化就是找到系统处理中的瓶颈以及去除这些的过程，性能优化其实是对 OS 各子系统达到一种平衡的定义。 #
 *  
 *  具体步骤如下：
 *  # **系统的运行状况： CPU -> MEM -> DISK-> NETWORK -> application** #
 *  #  #
 *  # **分析是否有瓶颈(依据当前应用需求)** #
 *  # **调优(采取一定措施使变得优异)** #
 *  
 *  这些子系统之间关系是相互彼此依赖的，任何一个高负载都会导致其他子系统出现问题.比如:
 *  大量的网页调入请求导致内存队列的拥塞；
 *  网卡的大吞吐量可能导致更多的 CPU 开销；
 *  大量的 CPU 开销又会尝试更多的内存使用请求；
 *  大量来自内存的磁盘写请求可能导致更多的 CPU 以及 IO 问题；
 *  所以要对一个系统进行优化,查找瓶颈来自哪个方面是关键,虽然看似是某一个子系统出现问题,其实有可能是别的子系统导致的。
 *  调优就像医生看病，因此需要你对服务器所有地方都了解清楚。

--------------------

*  # 查看 CPU 负载相关工具 #
 *  使用 **uptime** 命令查看系统 **cpu** 负载
 *   uptime   
     07:38:47 up 16:41,  1 user,  load average: 0.04, 0.04, 0.08
 *  其内容如下：  
    07:38:47        当前时间  
    up 16:41         当前系统运行时间，上次开机（重启）到目前的运行时间  
    1 user             当前登录用户数  
    load average:   0.04, 0.04, 0.08  
    系统负载，即任务队列的平均长度。 三个数值分别为 1 分钟、5分钟、15 分钟前到现在的平均值

![2021071707411639.png][]

*  例：找出前当系统中，CPU 负载过高的服务器？  
    服务器 1： load average: 0.15, 0.08, 0.01 1 核  
    **服务器 2： load average: 4.15, 6.08, 6.01 1 核**   
    服务器 3： load average: 7.15, 7.08, 7.01 4 核   
    答案：服务器 2 负载过高。
 *  
 *  **经验：单核心，1 分钟的系统平均负载不要超过 3，就可以，4 核心不要超过 12，这是个经验值。**
 *  
 *  **所以如果服务器的 CPU 为 1 核心，则 load average 中的数字 >=3 负载过高，如果服务器的 CPU 为4 核心，则 load average 中的数字 >=12 负载过高。**
 *  
 *  **任务队列的平均长度是：是系统等待运行队列的长度与当前所有 CPU 中正在运行的工作的和。**
 *  
 *  **就像如图大家正在 3 号窗口排队买票，3 号窗口的队列就是 4 人。  
    大厅排除买票：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 1][]

*  如下图单核 cpu 的任何队列长度为 3，包括正在运行的进程

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 2][]

*  **找出系统中使用 CPU 最多的进程**  
    运行 top 命令，按下大写的 P，可以按 CPU 使用率来排序显示

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 3][]

*  ### **top 中 VIRT、RES 和 SHR 的含意：**   VIRT：virtual memory usage 虚拟内存   进程“需要的”虚拟内存大小，包括进程使用的库、代码、数据等；   假如进程申请 70m 的内存，但实际只使用了 7m，那么它会增长 70m，而不是实际的使用量。 ###
 *  ### RES：resident memory usage 常驻内存   进程当前使用的内存大小，但不包括 swap out；   包含其他进程的共享；   如果申请 70m 的内存，实际使用 7m，它只增长 7m，与 VIRT 相反；   关于库占用内存的情况，它只统计加载的库文件所占内存大小。 ###
 *  ### SHR：shared memory 共享内存   除了自身进程的共享内存，也包括其他进程的共享内存；   虽然进程只使用了几个共享库的函数，但它包含了整个共享库的大小；   计算某个进程所占的物理内存大小公式：RES – SHR；   swap out 后，它将会降下来。 ###
 *  #  #
 *  # htop 工具 #
 *

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 4][]

*  在上图中将输出的界面划分成了四个区域，其中：
 *  **上左区：显示了CPU、物理内存和交换分区的信息**
 *  **上右区：显示了任务数量、平均负载和连接运行时间等信息**
 *  **进程区域：显示出当前系统中的所有进程**
 *  **操作提示区：显示了当前界面中F1-F10功能键中定义的快捷功能**

*  M：按照内存使用百分比排序，对应MEM%列；
 *  P：按照CPU使用百分比排序，对应CPU%列；
 *  T：按照进程运行的时间排序，对应TIME+列；
 *  K：隐藏内核线程；
 *  H：隐藏用户线程；
 *  \#：快速定位光标到PID所指定的进程上。

*  
 *  F1：显示帮助信息；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 5][]

*   F2：配置界面中的显示信息

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 6][]

*  可以根据自己的需要修改显式模式以及想要显示的内容
 *  比如：以LED的形式显示CPU的使用情况，并且在左边的区域添加hostname，在右边的区区域添加clock
 *  方向键选择左右上下

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 7][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 8][]

*  F3：进程搜索；
 *  再次按下 F3 搜索下一个

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 9][]

*  F4：进程过滤器； 从上面的结果可以看出search和filter的区别： search会将光标定位到符合条件的进程上，通过F3键进行逐个查找；而filter会直接将符合条件的进程筛选出来。 search和filter都使用ESC键来取消功能。
 *  F5：显示进程树；
 *  F6：排序：
 *  比如 P  选择 CPU 列，按照 PID  回车排序

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 10][]

*  F7：减小nice值； F8：增加nice值； 直接修改光标选取的进程的nice值：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 11][]

*  F9：杀掉指定进程；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 12][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 13][]

*   F10：退出htop。 空格键：用于标记选中的进程，用于实现对多个进程同时操作；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 14][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 15][]

*  \-u：显示指定用户的进程；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 16][]

*   l：显示光标所在进程的文件列表;

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 17][]

*  大写 i 反转显示

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 18][]

--------------------

*  **按照实际使用 CPU，从大到小排序显示所有进程列表  
    ps -aux --sort -pcpu | more                 \#按 cpu 降序排序**（使用率） 
 *  注: -pcpu 可以显示出进程绝对的路径，方便找出木马程序运行的路径。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 19][]

*  **查看 CPU 信息**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 20][]

*  ### 使用 mpstat 查看 CPU 运行情况   rpm -qf \`which mpstat\`                 \#查看安装 mpstat 命令的安装包。   sysstat-10.1.5-19.el7.x86\_64       \#此软件包，包括很多查看系统状态的软件包。   mpstat   ###

![20210717084301541.png][]

*  注：每列参数说明  
    **usr:用户空间 CPU 使用占比。  
    nice:低优先级进程使用 CPU 占比。nice 值大于 0。  
    sys:内核空间 CPU 使用占比。  
    iowait:CPU 等待 IO 占比。  
    irq:CPU 处理硬中断占比。  
    soft:CPU 处理软中断占比。  
    idle:CPU 空闲时间占比。  
    guest 与 steal 与虚拟机有关，暂不涉及。**
 *  
 *  **mpstat -P ALL \#查看所有 CPU 运行状态**

![20210717084420934.png][]

*  mpstat -P ALL 1 10                        ＃ 一秒钟刷新一次 连续刷新 10 次

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 21][]

*  ### 查看 Memory 运行状态相关工具   free 命令查看内存使用情况 ###
 *  注：在 centos7 系统中 available 这一列是真正可用内存。
 *  available 包括了 buff/cache 中一些可以被释放的内存。当物理内存不够用的时候，内核会把非活跃的数据清空。

![20210717084606458.png][]

*   通过/proc 目录，查看非活跃的内存：  
    /proc 文件系统下的多种文件提供的系统信息不是针对某个特定进程的，而是能够在整个系统范围的上下文中使用。可以使用的文件随系统配置的变化而变化。  
    cat /proc/meminfo

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 22][]

*   注：当内存不够用时，kernel 总是把不活跃的内存交换到 swap 空间。如果 inactive 内存多时，加swap 空间可以解决问题，而 active 多，则考虑加内存。
 *  # 找出系统中使用内存最多的进程？   方法 1：运行 top，然后按下大写的 M 可以按内存使用率来排序显示 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 23][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 24][]

*  # 方法 2：按照实际使用内存，从大到小排序显示所有进程列表 #
 *  ps -aux --sort -rss | more 内存降序排序(去掉减号就是升序)
 *  或：
 *  ps -aux --sort -rss > a.log   
 *

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 25][]

--------------------

*  # 查看 IO 运行状态相关工具 #
 *  # 查看文件系统块大小  #
 *  # 对于 ext4 文件系统，查看文件系统块大小  #
 *  tune2fs -l /dev/sda1 | grep size

![20210717085515819.png][]

*  对于 xfs 文件系统，查看文件系统块大小

xfs\_growfs -l /dev/sda1 |grep bsize

![20210717085722511.png][]

*  # 找出系统中对磁盘读写最多的进程 #
 *  ###  通过iostat命令查看IO是否存在瓶颈 ###
 *  ### iostat -d -k -p /dev/sda  ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 26][]

*    常用参数：

\-d 仅显示磁盘统计信息。  
\-k 以K为单位显示每秒的磁盘请求数,默认单位块。  
\-p device | ALL 用于显示块设备及系统分区的统计信息。

*  注：  
    每列含意：  
    kB\_read/s 每秒从磁盘读入的数据量,单位为K.  
    kB\_wrtn/s 每秒向磁盘写入的数据量,单位为K.  
    kB\_read 读入的数据总量,单位为K.  
    kB\_wrtn 写入的数据总量,单位为K.
 *  测试，给磁盘写入一些内容， 写入时尽可能不读磁盘？  
    **dd if=/dev/zero of=/tmp/test.txt bs=10M count=500 ; sync **  
    读入的数据用/dev/zero，/dev/zero不会读磁盘的。  
    sync       \#把内存中的数据快速写到磁盘上。 只做dd不执行sync，不容易看不出写入效果
 *  另外开一个 shell
 *  watch iostat -p sda -dk

![20210717090217457.png][]

![20210717090322864.png][]

![20210717090342171.png][]

![2021071709035588.png][]

*  # **如果服务器很卡，查看CPU使用率不高，内存也够用，但就是卡，尤其是打开新程序或文件时，更卡。此时是哪出问题了？ ** #
 *  # 这时系统的瓶颈在哪里？ 在磁盘IO上。使用iotop命令，查看哪个进程使用磁盘读写最多。 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 27][]

*  ### iotop的参数：   \-o, -only 只显示在读写硬盘的程序   \-d SEC, -delay=SEC 设定显示时间间隔。 刷新时间   iotop 常用快捷键：   <- / ->：左右箭头：改变排序方式，默认是按 IO 排序。   r：改变排序顺序。   o：只显示有 IO 输出的进程。   p：进程/线程的显示方式的切换。   a：显示累积使用量。   q：退出，按 q 或 ctrl+C ###
 *  
 *  ### 例1：找出使用磁盘最多的进程  ###
 *  iotop -o -d 1                \#显示正在使用磁盘的进程

![20210717090743728.png][]

*  在另一个终端对磁盘进行大量读操作，执行：  
    find /  
    查看结果：

![20210717090802285.png][]

--------------------

*  # 查看 Network 运行状态相关工具，找出系统中使用网络最多的进程   使用nload监控总体带宽使用情况 #

yum install nload -y

*  **开始监控  
    nload**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 28][]

*  然后另一个终端上运行ab，开始测试：
 *  ab -n 700 -c 2 http://www.baidu.com/index.html                          \#产生一些测试数据  
    查看结果：

![20210717091132934.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 29][]

*  #  使用nethogs找出使用带宽最多的进程 #
 *  yum安装  
    yum install -y nethogs  
    nethogs

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 30][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 31][]

*  在另一个终端生成一些数据：  
    wget http://issuecdn.baidupcs.com/issue/netdisk/yunguanjia/BaiduNetdisk\_5.5.3.exe  
    查看结果，找出wget是使用流量最多的进程

![20210717091610286.png][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 32][]

--------------------

*  # 查看系统整体运行状态   使用 vmstat 查看内存及系统整体运行状态  #
 *   vmstat ：命令是最常见的 Linux/Unix 监控工具，可以展现给定时间间隔的服务器的状态值，包括服务器的 CPU 使用率，MEM 内存使用，VMSwap 虚拟内存交换情况，IO 读写情况。
 *  使用 vmstat 可以看到整个机器的 CPU，内存，IO 的使用情况，而不是单单看到各个进程的 CPU 使用率和内存使用率。 比 top 命令节省资源。
 *  注：当机器运行比较慢时，建议大家使用 vmstat 查看运行状态，不需要使用 top，因 top 使用资源比较多。
 *  例：

![20210717091744620.png][]

*  每一列参数作用：  
    r        运行状态的进程个数 。展示了正在执行和等待 cpu 资源的任务个数。当这个值超过了 cpu 个数，就会出现 cpu 瓶颈 
 *  b       不可中断睡眠 正在进行 i/o 等待－－阻塞状态的进程个数 进程读取外设上的数据，等待时  
    free   剩余内存，单位是 KB  
    buff          \#内存从磁盘读出的内容  
    cache   \#内存需要写入磁盘的内容  
    si swapin swap      换入到内存  
    so swapout           内存换出到 swap 换出的越多，内存越不够用  
    bi blockin              从硬盘往内存读。 单位是块。 把磁盘中的数据读入内存  
    bo blockout          从内存拿出到硬盘 （周期性的有值） 写到硬盘  
    \#判断是读多还是写多，是否有 i/o 瓶颈  
    in                        系统的中断次数，cpu 调度的次数多  
    cs                       每秒的上下文切换速度   
    CPU                  上下文切换－－程序在运行的时候，CPU 对每个程序切换的过程。  
    更多内存参以一下表格： vmstat 每个字段含义说明

--------------------

*  使用 sar 命令记录系统一段时间的运行状态
 *  sar 工具可以把检查到的信息保存下来，存在/var/log/sa 目录下。
 *  sar 默认显示每10分钟统计一次状态信息（从装 sysstat 包开始）
 *  
 *  **sar 命令行的常用格式： sar \[options\] \[-A\] \[-o file\] t \[n\]**  
    在命令行中，n 和 t 两个参数组合起来定义采样间隔和次数，t 为采样间隔，是必须有的参数，n 为采样次数，是可选的，默认值是 1，-o file 表示将命令结果以二进制格式存放在文件中，file 在此处不是关键字，是文件名。options 为命令行选项
 *  sar 命令的选项很多 下面只列出常用选项：
 *  下面只列出常用选项：  
    \-A：所有报告的总和。  
    \-n：网络接口的情况。  
    \-u：CPU 利用率  
    \-v：进程、I 节点、文件和锁表状态。  
    \-d：硬盘使用报告。  
    \-r：没有使用的内存页面和硬盘块。  
    \-g：串口 I/O 的情况。  
    \-b：缓冲区使用情况。  
    \-a：文件读写情况。  
    \-c：系统调用情况。  
    \-R：进程的活动情况。  
    \-y：终端设备活动情况。  
    \-w：系统交换活动。  
    \-o 文件名：打印到屏幕并将采样结果以二进制形式存入当前目录下的文件中。  
    \-f 文件名：查看之前保存的二进制文件。  
    \-d：显示磁盘。  
    \-d 1 70 \#必须得指定次数。  
    \-c：每秒创建进程的个数。  
    \-i 1 7 \#指定时间间隔。  
    \-P：查看 cpu。  
    \-r：查看内存。  
    \-w：每秒上下文切换次数。  
    \-o /cpu.sar \#保存并显示。  
    \-f cpu.sar \#读取。
 *  
 *  每 2 秒采样一次，连续采样 5 次，观察 CPU 的使用情况，并将采样结果以二进制形式存入当前目录下的文件 cpu.sar 中  
    **sar -u 2 5 -o cpu.sar **        \#屏幕显示以一下内容，同时内容也会写到当前目录的./cpu.sar 中

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 33][]

*  在显示内容包括：  
    %usr：CPU 处在用户模式下的时间百分比。  
    %system：CPU 处在系统模式下的时间百分比。  
    %iowait：CPU 等待输入输出完成时间的百分比。  
    %idle：CPU 空闲时间百分比。  
    **在所有的显示中，我们应主要注意****%iowail 和%idle**
 *  **%iowail 的值过高，表示硬盘存在 I/O 瓶颈，%idle 值高，表示 CPU 较空闲，如果%idle 值高但系统响应慢时，有可能是 CPU 等待分配内存，****此时应加大内存容量**
 *  **%idle 值如果持续低于 7，那么系统的 CPU 处理能力相对较低，表明系统中最需要解决的资源是 CPU**
 *  **查看二进制文件 cpu.sar 中的内容  
    sar -u -f cpu.sar   
    注：sar 命令即可以实时采样，又可以对以往的采样结果进行查询**

![20210717092833984.png][]

*  查看 sar 的计划任务并读取日志  
    查看 sar 的计划任务cat /etc/cron.d/sysstat                                                                                                                          ???127?  
    \# Run system activity accounting tool every 10 minutes  
    \*/10 \* \* \* \* root /usr/lib64/sa/sa1 1 1                     默认每10分钟执行一次  
    \# 0 \* \* \* \* root /usr/lib64/sa/sa1 600 6 &  
    \# Generate a daily summary of process accounting at 23:53  
    53 23 \* \* \* root /usr/lib64/sa/sa2 -A

![20210717092922583.png][]

*   注：生成的日志位置：
 *   ls /var/log/sa

![20210717093130527.png][]

*   读取日志  
    ls /var/log/sa                \#只要安装 sar 后就会定期收集系统信息。
 *  注：sa 开头的文件不能使用 cat 命令进行查看，只能使用 sar -f 进行查看，文件名命名规则 sa+日期，sa01 表示这个月的第一天。文件名会根据日期进行排序，sa01、sa02 ……
 *  使用参数-n 查看网络接口流量情况：  
    sar -n DEV -f /var/log/sa/sa16          \#查看网络相关信息。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 34][]

*  查看内存和硬盘  
    sar -r -f /var/log/sa/sa17  
    \-r 查看内存

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 35][]

*   sar -d -f /var/log/sa/sa17

\-d：硬盘使用报告

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 36][]

*  # sar 最大特点是可以监控所有状态，sar 的其他使用方法如下：   sar -r 1         \#查看内存   sar -n ALL    \#查看所有   sar -b 1 7     \#缓冲区使用情况，每秒刷新一次，查看 7 次   sar -I ALL 1 7   sar -r -f /tmp/file -n -r -b -m   sar -s 15:00:00 -e 15:30:00           \#查看某个时间段，系统运行情况   sar -s 15:00:00 -e 15:30:20 -f /var/log/sa/sa17   sar -r -s 15:00:00 -e 15:30:20 -f /var/log/sa/sa17 #
 *

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 37][]

--------------------

*  # CPU-IO-网络-内核参数的调优 #
 *  调 整 nice 值 改 变 进 程 优 先 级  
    nice 概述：在 LINUX 系统中，Nice 值的范围从-20 到+19（不同系统的值范围是不一样的），正值表示低优先级，负值表示高优先级，值为零则表示不会调整该进程的优先级。具有最高优先级的程序，其 nice 值最低，所以在 LINUX 系统中，值-20 使得一项任务变得非常重要；与之相反，如果任务的 nice为+19，则表示它是一个高尚的、无私的任务，允许所有其他任务比自己享有宝贵的 CPU 时间的更大使用份额，这也就是 nice 的名称的来意。默认优先级是 0
 *  在命令运行前，调整进程 nice 值，让进程使用更多的 CPU
 *  语法： nice -n 优先级数字 命令
 *  例：将 vim test.txt 命令的优先级，从默认的 0 级别调高到-5 级别  
     
 *  pidof vim   得到进程的 PID
 *  top -p PID    只查看某进程
 *  看得出默认 nice 值为 0
 *

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 38][]

*  nice -n -5 vim test.txt             \#先不要退出这个 vim 命令，另外打开一个shell
 *  NI 值 为5

![20210718081716235.png][]

*  **使用 renice 修改正在运行的进程的优先级  
    语法：renice -n \[NUM\] PID      \#修改进程优先级**
 *  **将先前 vim 的 PID 92336  优先级调整为级别 10**
 *  **renice -n 10 92336**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 39][]

*  ###  注:进程优先级不可以超过 -20 到 19 范围 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 40][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 41][]

*  设 置 进 程 的 CPU 亲 和 力  
    taskset 作用：在多核的情况下，可以认为指定一个进程在哪颗 CPU 上执行程序，减少进程在不同CPU 之前切换的开销。  
    安装 taskset 命令： 
 *  yum -y install util-linux

![20210718082516800.png][]

*  taskset 语法： taskset -cp \[CPU ID 号\] 命令或进程 ID  
    常用参数：  
    \-p, --pid 在已经存在的 pid 上操作  
    \-c, --cpu-list 以列表格式显示和指定 CPU
 *  服务器是 4 核 CPU ，指定 vim 命令在第一个 CPU 上运行 
 *   taskset -c 0 vim test.txt        \#第一个 CPU 的 ID 是 0。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 42][]

*  查 sshd 进程运行在哪几个 CPU 上
 *  pidof sshd  
    91909 91586 87896 82726 6471  
    taskset -cp 91586  
    pid 91586's current affinity list: 0-3         \#0-3 说明 sshd 进程可以使用 4 个 CPU 核心处理数据。

![20210718083053149.png][]

*   指定 vim c.txt 程序运行在第 2 和第 4 个 CPU 上

taskset -c 1,3 vim test.txt

![20210718083345489.png][]

*  # 使 用 vmstat 找 出 系 统 中 存 在 瓶 颈   CPU 利用率比例分配：   如果一个 CPU 被充分使用，利用率分类之间均衡的比例应该是。 #

65%  70% User Time         \#用户态（通常指我们运行的服务和程序）。  
30%  35% System Time    \#内核态。  
0%  5% Idle Time              \#空闲。

*   Context Switches  上下文切换的数目直接关系到 CPU 的使用率，如果 CPU 利用率保持在上述均衡状态时，有大量的上下文切换是正常的。 
 *  上下文切换指的就是 cpu 中寄存器数据的写入和读出。每个进程在使用 cpu 时，都需要把自己的数据先写入 cpu 的缓存（寄存器）中，然后 cpu 才能根据缓存中的数据来计算。
 *   一台 4 核心，8G 内存的服务器，根据 vmstat 运行的结果，来分析系统中存在的问题。  
    学会这个思路，后期就可以很轻松分析出 8 核心，16G 或 8 核心，32G 服务器的瓶颈。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 43][]

*  # vmstat 输出每列字段的意义： #
 *  **Procs（进程）：**  
    r: The number of processes waiting for run time. **等待运行的进程数。如果等待运行的进程数越多，意味着 CPU 非常繁忙**。另外，如果该参数**长期大于 cpu 核心数 3 倍**，说明 CPU 资源**可能存在较大的瓶颈**。  
    b: The number of processes in uninterruptible sleep.处在非中断睡眠状态的进程数。即等待 IO 的进程数量。
 *  
 *  **Memory（内存）：**  
    swpd: the amount of virtual memory used.已使用的虚拟内存大小。**如果虚拟内存使用较多，可能系统的物理内存比较吃紧**，需要采取合适  
    的方式来减少物理内存的使用。swapd 不为 0，并不意味物理内存吃紧，如果 swapd 没变化，si、so 的值长期为 0,这也是没有问题的 。  
    free: the amount of idle memory.空闲的物理内存的大小  
    buff: the amount of memory used as buffers.用来做 buffer（缓存，主要用于块设备缓存）的内存数，单位：KB  
    cache: the amount of memory used as cache.用作缓存的内存大小，如果 cache 的值大的时候，说明 cache 处的文件数多，如果频繁访问到  
    的文件都能被 cache 处，那么磁盘的读 IO bi 会非常小。单位：KB  
     
 *  **Swap（交换分区）**
 *  si: Amount of memory swapped in from disk (/s).  
    **从磁盘写入到 swap 虚拟内存的交换页数量，单位：KB/秒。如果这个值大于 0，表示物理内存不够用或者内存泄露了。**  
    so: Amount of memory swapped to disk (/s).  
    **从 swap 虚拟内读出的数据**。即从 swap 中的数据写入到磁盘的交换页数量，单位：KB/秒，  
    **如果这个值大于 0，表示物理内存不够用或者内存泄露了。**
 *    
    **内存够用的时候，si so  2 个值都是 0，如果这 2 个值长期大于 0 时，系统性能会受到影响，磁盘 IO和 CPU 资源都会被消耗。**
 *    
    **当看到空闲内存（free）很少的或接近于 0 时，就认为内存不够用了，这个是不正确的。不能光看这一点，还要结合 si 和 so。如果 free 很少，但是 si 和 so 是 0，那么不用担心，系统性能这时不会受到影响的。**
 *    
    **IO**（这里指 Input/Output Memery 的数据，**即 bi：进入内存，bo：从内存中出去**）  
    bi: Blocks received from a block device (blocks/s).  
    每秒从块设备接收到的块数，单位：块/秒 也就是读块设备。**bi 通常是读磁盘的数据**  
    bo: Blocks sent to a block device (blocks/s).  
    每秒发送到块设备的块数，单位：块/秒 也就是写块设备。**bo 通常是写磁盘的数据**  
     
 *  **System（系统）**  
    in: The number of interrupts per second, including the clock.  
    每秒的中断数，包括时钟中断。  
    **cs: The number of context switches per second.**  
    每秒的环境（上下文）切换次数。比如我们调用系统函数，就要进行上下文切换，而**过多的上下文切换会浪费较多的 cpu 资源，这个数值应该越小越好。**
 *  **CPU（使用 cpu 时间的百分比%，最大 100%）**  
    us: Time spent running non-kernel code. (user time, including nice time)  
    用户 CPU 时间(非内核进程占用时间)（单位为百分比）。 **us 的值比较高时，说明用户进程消耗的 CPU 时间多**  
    sy: Time spent running kernel code. (system time)  
    系统使用的 CPU 时间（单位为百分比）。**sy 的值高时，说明系统内核消耗的 CPU 资源多，这并不是良性表现，我们应该检查原因。**  
    id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.  
    空闲的 CPU 的时间(百分比)，在 Linux 2.5.41 之前，这部分包含 IO 等待时间。  
    **wa: Time spent waiting for IO. Prior to Linux 2.5.41, shown as zero.**  
    等待 IO 的 CPU 时间，这个值为 0 .这个指标意味着 CPU 在等待硬盘读写操作的时间，用百分比表示。**wait 越大则机器 io 性能就越差。说明 IO 等待比较严重，这可能由于磁盘大量作随机访问造成，也有可能磁盘出现瓶颈（块操作）**。  
    st: 虚拟机占用 cpu 时间的百分比。如果 centos 系统上运行了 kvm 虚拟机，而 kvm 虚拟上又运行了几个虚拟机，那么这个值将显示这个几个正在运行的虚拟机从物理机中窃取 CPU 运行时间的百分比。 
 *  当系统刚开机后，一切正常时，vmstat 的状态。  
    vmstat 1 10

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 44][]

*  注：根据观察值，我们可以得到以下结论:  
    1、第 1 列 r（run），有个 1，很多次是 0，说明当前系统中正在运行的进程不多，此值大于 cpu核心数 3 倍时，我们认为是 cpu 是繁忙的。当前情况下： r > 12，才算忙。  
    2、第 4 列 free 是物理内存剩余数。默认单位是 KB，现还有 7284516KB，所以内存肯定够用。  
    3、第 7 和 8 列 swap 是 swap 内存交换分区使用情况。**如果这两列有数据，说明我们已经使用了 swap交换分区了，那么系统的内存肯定不够用了，需要加内存。**  
    4、第 9 和 10 列 io，**如果 io 这组数据中 bi 比较大，说明从磁盘读进内存的数据比较大，即读磁盘数据多。bo 比较大，说明从内存写入到磁盘的数据比较多，即说明写磁盘比较多。**  
    5、第 13 和 15 列 cpu 数据组中的 us 是用户太进程使用 cpu 时间的百分比。如果 us 列数据比较大，说明用户态的进程如 apache，mysql 等服务使用 cpu 比较多。 id 这列是 cpu 空闲时间（%）。此列最大值是 100%  
    6、**第 16 列，即倒数第二列 wa（等待 IO 所消耗的 CPU 时间百分比），如果此占用 cpu 的百分比比较大，如到达了 40%，说明磁盘读写速度太慢，IO 有瓶颈了。具体是 bi 或 bo 的问题，可以查看一下 bi和 bo 列的数值。如果 bi 列值很大，说明进程在等待写入磁盘数据时，占用了大量 cpu。**

上传一个比较大的文件到 linux 系统中，分析系统资源使用情况。上传文件是只写磁盘，不读磁盘。  
vmstat 1 1000               \#开始长时间监控系统。  
然后开始上传一些文件系统中。上传的文件大家可以随意找一些文件上传，只要大于 1G 就可以了。大于 1G，可以上传的时间长一些，方便看出来效果。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 45][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 46][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 47][]

*  注：根据观察值，我们可以得出结论：
 *  **因为只是上传文件到 linux 系统中，在上传文件过程中没有读磁盘，所以 bi 的值一直为 0；**
 *  **但是上传文件时会写入磁盘，所以 bo 这列会有大量数据。**
 *  **r 列，free 列，us 列，id 列，wa 列数据不多，说明 cpu，内存，io 都还可以，压力不大。**

--------------------

*  将/lib64 目录复制到/opt 下，模拟生产环境下备份数据的情景。在复制的过程中查看一下系统的状态。
 *  du -sh /lib64/  
    228M /lib64/  
    cp -r /lib64/ /opt/
 *

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 48][]

*  注：根据观察值，我们可以得出结论：  
    **因为我们是复制文件，所以 bi 和 bo 都会有大量数据。  
    r 列，free 列数据不大，说明正在运行的进程数不多，内存也够用。  
    查看 r 列最大数据是 3，r 列如果超过 12 则认为 cpu 核心数不够用。所以当前运行的进程不多，cpu 核心数够用。**
 *  **查看 us 列、sy 列、wa列、使用 cpu 不多**，**如果 wa 列使用 cpu 很多。说明当前系统的瓶颈是磁盘读写太慢。**因为大量进程都处在等待读写磁盘上这件事上。
 *  **总结：通过 wa 列是最容易看出磁盘读写速度是否太慢。**

--------------------

*   使用  apache 的压测工具 ab 对系统进行测试
 *  ab -n 500000 -c 200 http://192.168.2.3/index.html

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 49][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 50][]

*  ###  注：根据观察值，我们可以得出结论:   **r 列有几个数值已经超过 12 了，说明 cpu 核心数不够用了。** ###
 *  **wa 列为 0，说明在读写磁盘等待上，没有占用 cpu。**
 *  **这样情况就是服务器上运行了大量进程，在消耗 cpu。可以使用 ps 查看一下有哪个进程，另外，也可以运行 top 命令再按 P，来查看一下哪些进程在大量使用 cpu。**
 *  扩展：关于 buff 和 cache 内存  
    BUFFER inode 节点索引缓存；   CACHE block 块/页缓存。  
    buffers             \#缓存从磁盘读出的内容 ，这种理解是片面的  
    cached            \#缓存需要写入磁盘的内容 ，这种理解是片面的  
    不过现在在 centos7 下，free 命令已有变化，free 直接给出了可用空余内存 available。增加了-h选项，支持以人性化的单位（K/M/G）显示各个数值。如下：

![20210718091800747.png][]

--------------------

*  # 有关磁盘 I/O 的调优   ulimit 资 源 限 制 #
 *  限制用户资源配置文件：/etc/security/limits.conf
 *  
 *  每行的格式：用户名/@用户组名 类型(软限制/硬限制) 选项 值
 *  
 *  永久修改一个进程可以打开的最大文件数
 *  vim /etc/security/limits.conf      \#在文件的最后追加以下内容
 *  \*  -  nofile 655350      \#理论上大于 65535 即可
 *

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 51][]

*  注：soft 是一个警告值，而 hard 则是一个真正意义的阀值，超过就会报错。一般把 soft 和 hard 都配置成一样的值。 最大打开的文件数以文件描叙符 file descripter 计数)。
 *  ulimit -n             \#查看一个进程可以打开的文件数，默认是 1024
 *  
 *  **init 6                  \#想要刚修改的 limits.conf 中配置永久生效，必须重启系统**
 *  临时修改  
    ulimit -n 655350         \#不用重启系统。  
    ulimit -n 
    
    ![20210718092457224.png][]
 *  nproc \#配置一个用户可以打开的最大进程数  
    vim /etc/security/limits.d/20-nproc.conf   
    改：  
    5 \* soft nproc 4096  
    为：  
    5 \* soft nproc 65535  
    6 \* hard nproc 65535

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 52][]

*  临时修改
 *  ulimit -u 65535 
 *  注:如果默认一个用户，比如 apache 可用的最大进程数是 1024.那么 apache 用户启动的进程就数就不能大于 1024了。 
 *  ### 查询系统中进程占用的句柄数 ###
    
    使用的命令是：
 *  lsof -n|awk '\{print $2\}'|sort|uniq -c|sort -nr|more

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 53][]

--------------------

*   查 看 所 有 的 资 源 限 制 信 息

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 54][]

*  **core file size (blocks, -c) 0 kdump         转储功能打开后产生的 core file 大小限制  
    data seg size (kbytes, -d) unlimited       数据段大小限制  
    scheduling priority (-e) 0  
    file size (blocks, -f) unlimited                 文件大小限制  
    pending signals                 (-i) 31117  
    max locked memory (kbytes, -l) 64  
    max memory size (kbytes, -m) unlimited  
    open files (-n) 655350                            打开的文件个数限制  
    pipe size (512 bytes, -p) 8                      管道大小的限制  
    POSIX message queues (bytes, -q) 819200     消息队列大小real-time priority (-r) 0  
    stack size (kbytes, -s) 8192                  栈大小  
    cpu time (seconds, -t) unlimited           CPU 时间使用限制  
    max user processes (-u) 65535            最大的用户进程数限制  
    virtual memory (kbytes, -v) unlimited    虚拟内存限制**  
    **file locks (-x) unlimited **
 *

--------------------

*  测 试 硬 盘 速 度  
    一般情况下使用 hdparm 来测试磁盘顺序读的速度。dd 命令用来测试磁盘顺序写的速度。  
    hdparm 命令常用参数  
    参数：  
    \-t perform device read timings            \#不使用预先的数据缓冲, 标示了 Linux 下没有任何文件系统开销时磁盘可以支持多快的连续数据读取. perform \[pəˈfɔ:m\]                                \#执行  
    \--direct Use O\_DIRECT to bypass page cache for timings         \#直接绕过缓存进行统计数据
 *  
 *  hdparm -t --direct /dev/sda

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 55][]

*   注： 弹出的含意是 3.00 秒中从硬盘缓存中读 5302M，平均每秒读 1764.87MB/sec
 *  使用 dd 命令测试磁盘 IO 的顺序写和读速度  
    在使用前首先了解两个特殊设备：/dev/null 伪设备，回收站.写该文件不会产生 IO 开销；/dev/zero 伪设备，会产生空字符流，读该文件不会产生 IO 开销
 *  dd if=/dev/zero of=/tmp/test.dbf bs=1M count=5000 oflag=direct,nonblock  
    5000+0 records in  
    5000+0 records out  
    5242880000 bytes (5.2 GB) copied, 23.4296 s, 224 MB/s

![20210718094258270.png][]

*   注：可以看到，在  23.4296 秒的时间里，生成 5000M 的一个文件，IO 写的速度约为 224 MB/秒，这就是硬盘顺序写速度了。当然这个速度可以多测试几遍取一个平均值。  
    注：oflag=direct,nonblock 中的 direct 表示读写数据采用直接 IO 方式；nonblock 表示读写数据采用非阻塞 IO 方式，这样绕开缓存，测试的更准确。  
    总结：在生产环境下，建议使用 hdparm 来测试磁盘读，使用 dd 来测试磁盘写速度 
    
    ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 56][]
 *   time 命 令 测 试 进 程 运 行 时 间  
    time 命令： 执行命令并计时   
    测试 dd 命令使用时间和开销
 *  time dd if=/dev/zero of=/tmp/test.dbf bs=1M count=5000 oflag=direct,nonblock

![20210718094901509.png][]

*   1)实际时间(real time): 从 command 命令行开始执行到运行终止的消逝时间；

2)用户 CPU 时间(user CPU time): 命令执行完成花费的用户 CPU 时间，即命令在用户态中执行时间总和；  
3)系统 CPU 时间(system CPU time): 命令执行完成花费的系统 CPU 时间，即命令在核心态中执行时间总和。  
其中，用户 CPU 时间和系统 CPU 时间之和为 CPU 时间，即命令占用 CPU 执行的时间总和。实际时间要大于 CPU 时间，因为 Linux 是多任务操作系统，往往在执行一条命令时，系统还要处理其它任务。  
排队时间没有算在里面。  
另一个需要注意的问题是即使每次执行相同命令，但所花费的时间也是不一样，其花费时间是与系统运行相关的

--------------------

*  # 内核参数调优 #
 *  使用netstat命令去查TIME\_WAIT状态的连接状态，输入下面的组合命令，查看当前TCP连接的状态和对应的连接数量：  
    `netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' ESTABLISHED 1 SYN_SENT 2 TIME_WAIT 49`
 *  调整下Linux的TCP内核参数，让系统更快的释放TIME\_WAIT连接。  
      
    用vim打开配置文件：`vim /etc/sysctl.conf`
    
    在这个文件中，加入下面的几行内容：  
    `net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 30`
    
    输入下面的命令，让内核参数生效：`sysctl -p`
 *  sysctl -p  
    net.ipv4.tcp\_syncookies = 1  
    net.ipv4.tcp\_tw\_reuse = 1  
    net.ipv4.tcp\_tw\_recycle = 1  
    net.ipv4.tcp\_fin\_timeout = 30
 *  简单的说明上面的参数的含义：
    
    net.ipv4.tcp\_syncookies = 1   \#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；  
    net.ipv4.tcp\_tw\_reuse = 1     \#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；  
    net.ipv4.tcp\_tw\_recycle = 1   \#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭；  
    net.ipv4.tcp\_fin\_timeout    \#修改系統默认的 TIMEOUT 时间。
 *  在经过这样的调整之后，除了会进一步提升服务器的负载能力之外，还能够防御小流量程度的DoS、CC和SYN攻击
 *  优化一下TCP的可使用端口范围，进一步提升服务器的并发能力。依然是往上面的参数文件中，加入下面这些配置：  
    `net.ipv4.tcp_keepalive_time = 1200 net.ipv4.ip_local_port_range = 10000 65000 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_max_tw_buckets = 5000`

![20210718100806291.png][]

*  这几个参数，建议只在流量非常大的服务器上开启，会有显著的效果。一般的流量小的服务器上，没有必要去设置这几个参数。
    
    net.ipv4.tcp\_keepalive\_time = 1200       \#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。  
    net.ipv4.ip\_local\_port\_range = 10000 65000    \#表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为10000到65000。（注意：这里不要将最低值设的太低，否则可能会占用掉正常的端口！）  
    net.ipv4.tcp\_max\_syn\_backlog = 8192     \#表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。  
    net.ipv4.tcp\_max\_tw\_buckets = 5000      \#表示系统同时保持TIME\_WAIT的最大数量，如果超过这个数字，TIME\_WAIT将立刻被清除并打印警告信息。默认为180000，改为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME\_WAIT套接字数量，但是对于 Squid，效果却不大。此项参数可以控制TIME\_WAIT的最大数量，避免Squid服务器被大量的TIME\_WAIT拖死
 *  
 *  # 内核其他TCP参数说明： #
 *    
    net.ipv4.tcp\_max\_syn\_backlog = 65536     \#记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M内存的系统而言，缺省值是1024，小内存的系统则是128。  
    net.core.netdev\_max\_backlog = 32768     \#每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。  
    net.core.somaxconn = 32768      \#web应用中listen函数的backlog默认会给我们内核参数的net.core.somaxconn限制到128，而nginx定义的NGX\_LISTEN\_BACKLOG默认为511，所以有必要调整这个值。
    
    net.core.wmem\_default = 8388608  
    net.core.rmem\_default = 8388608  
    net.core.rmem\_max = 16777216         \#最大socket读buffer,可参考的优化值:873200  
    net.core.wmem\_max = 16777216       \#最大socket写buffer,可参考的优化值:873200  
    net.ipv4.tcp\_timestsmps = 0      \#时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。  
    net.ipv4.tcp\_synack\_retries = 2    \#为了打开对端的连接，内核需要发送一个SYN并附带一个回应前面一个SYN的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYN+ACK包的数量。  
    net.ipv4.tcp\_syn\_retries = 2        \#在内核放弃建立连接之前发送SYN包的数量。  
    net.ipv4.tcp\_tw\_reuse = 0        \# 不开启重用。不允许将TIME-WAIT sockets重新用于新的TCP连接。
    
    net.ipv4.tcp\_wmem = 8192 436600 873200    \# TCP写buffer,可参考的优化值: 8192 436600 873200  
    net.ipv4.tcp\_rmem  = 32768 436600 873200   \# TCP读buffer,可参考的优化值: 32768 436600 873200  
    net.ipv4.tcp\_mem = 94500000 91500000 92700000  
    \# 同样有3个值,意思是:  
    net.ipv4.tcp\_mem\[0\]:低于此值，TCP没有内存压力。  
    net.ipv4.tcp\_mem\[1\]:在此值下，进入内存压力阶段。  
    net.ipv4.tcp\_mem\[2\]:高于此值，TCP拒绝分配socket。  
    上述内存单位是页，而不是字节。可参考的优化值是:786432 1048576 1572864
    
    net.ipv4.tcp\_max\_orphans = 3276800   \#系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS攻击，不能过分依靠它或者人为地减小这个值，更应该增加这个值(如果增加了内存之后)。  
    net.ipv4.tcp\_fin\_timeout = 30   \#如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60秒。2.2 内核的通常值是180秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB服务器，也有因为大量的死套接字而内存溢出的风险，FIN- WAIT-2的危险性比FIN-WAIT-1要小，因为它最多只能吃掉1.5K内存，但是它们的生存期长些。
 *  ###  **以上配置仅供参考，用于生产环境请根据自己的实际情况。** ###
 *  # **内核 TCP/IP 优化** #
 *  **sysctl -p  
    net.ipv6.conf.all.disable\_ipv6 = 1  
    net.ipv6.conf.default.disable\_ipv6 = 1  
    fs.file-max = 65535  
    net.ipv4.tcp\_max\_tw\_buckets = 60000  
    net.ipv4.tcp\_sack = 1  
    net.ipv4.tcp\_window\_scaling = 1  
    net.ipv4.tcp\_rmem = 4096 87380 4194304  
    net.ipv4.tcp\_wmem = 4096 16384 4194304  
    net.ipv4.tcp\_max\_syn\_backlog = 65536  
    net.core.netdev\_max\_backlog = 32768  
    net.core.somaxconn = 32768  
    net.core.wmem\_default = 8388608  
    net.core.rmem\_default = 8388608  
    net.core.rmem\_max = 16777216  
    net.core.wmem\_max = 16777216  
    net.ipv4.tcp\_timestamps = 1  
    net.ipv4.tcp\_fin\_timeout = 20  
    net.ipv4.tcp\_synack\_retries = 2  
    net.ipv4.tcp\_syn\_retries = 2  
    net.ipv4.tcp\_tw\_recycle = 0  
    net.ipv4.tcp\_syncookies = 1  
    net.ipv4.tcp\_tw\_reuse = 1  
    net.ipv4.tcp\_mem = 94500000 915000000 927000000  
    net.ipv4.tcp\_max\_orphans = 3276800  
    net.ipv4.tcp\_tw\_recycle = 1  
    net.ipv4.ip\_local\_port\_range = 1024 65535**

--------------------

*  列出服务器上当前所有四元组连接的数量
 *  ss -tan 'sport = :80' | awk '\{print $(NF)" "$(NF-1)\}' | sed 's/:\[^ \]\*//g' | sort | uniq -c
 *

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70]: /images/20220829/73af4706e65a4dda8085184092e95e45.png
[2021071707411639.png]: /images/20220829/d7c568d6de504baf981e2965334fa46d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 1]: /images/20220829/f4a99d119e264bc5903cef9a5e77b117.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 2]: /images/20220829/32bd9c61a4054dabb93eb4715600cb3b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 3]: /images/20220829/e83553f2315d430a81d02eeffb659deb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 4]: /images/20220829/25824ad4ee9441ebb2a397aff1d8390a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 5]: /images/20220829/8fefc946b1644a4983a91feae7e2533b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 6]: /images/20220829/cd4331f19e244b9499650cf23b42e777.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 7]: /images/20220829/73d0bd7e9f9d44958cb1b0e71663a6fb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 8]: /images/20220829/b047c2cb8ce04fa491c606aa80ca7e7a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 9]: /images/20220829/e97f318778ec4980bacf87dd11fedee4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 10]: /images/20220829/5ef7a70ce4d048c889f0cabf258fa551.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 11]: /images/20220829/e20f583bf08e4452bd342dc53a82acc0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 12]: /images/20220829/d8e58fee2e7648b58660a4ef6053a4a6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 13]: /images/20220829/a7eafa385d2c40c6b9757cd4d0950a2e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 14]: /images/20220829/3dc22a9196f247b785761fd183021872.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 15]: /images/20220829/824e8479bcdf40a5889807947cdac2cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 16]: /images/20220829/43851b966231447dae3c07b2a2c30b34.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 17]: /images/20220829/1e20bee1ab944386b2876625df3e52e8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 18]: /images/20220829/19e4538039334e0a829312afe4057f03.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 19]: /images/20220829/76887e35a86c44ca8f05d3ae7ab61a24.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 20]: /images/20220829/c68d4c6113874f0c902b2cb402b0f0ac.png
[20210717084301541.png]: /images/20220829/320fd88679414c50bd50a788352212d5.png
[20210717084420934.png]: /images/20220829/4653911c9ad842fb8da7bc6c801085ff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 21]: /images/20220829/7e9700e10f8841daae902053e034001e.png
[20210717084606458.png]: /images/20220829/ca2729da43e5478bb25e9b217d4137af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 22]: /images/20220829/dc13adffa772415f9bdea68db0592303.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 23]: /images/20220829/e78033d3f03e4270a8ae1e8eff4e0c4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 24]: /images/20220829/cea881874fe449cc9ece04e394dc1366.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 25]: /images/20220829/dcffac40114142c293a02182ee343c74.png
[20210717085515819.png]: /images/20220829/3542e648941947f68d9e2380698dd606.png
[20210717085722511.png]: /images/20220829/7382e5f42ac94ae3b5bdcef88f180013.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 26]: /images/20220829/4bf0dc92175946e883e542a9c2c916ee.png
[20210717090217457.png]: /images/20220829/af1b87d81b6549a78a065349aa671265.png
[20210717090322864.png]: /images/20220829/f77240851d6246809817d74cbed00747.png
[20210717090342171.png]: /images/20220829/0af9c3df690b4d98a48c4a4404ca0fcf.png
[2021071709035588.png]: /images/20220829/ac17ba667aa246a086e702f70dd0464e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 27]: /images/20220829/a5aea782de3b4484a900fc5ac548a620.png
[20210717090743728.png]: /images/20220829/b5f967963353461f8a13c0b025e2bde2.png
[20210717090802285.png]: /images/20220829/51b7debad06b4cdfa8aa02f3f0f1f633.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 28]: /images/20220829/ca431c107a244eb2a02c9e5cb15e136b.png
[20210717091132934.png]: /images/20220829/cfcaea1333ec4f4ca476a9cdb8faa470.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 29]: /images/20220829/55112bc964b847338b4b41dc0e5d82b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 30]: /images/20220829/3813e70f95794565b46e5906fb64265b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 31]: /images/20220829/9dfcfa9ea42c4c5e993011e864afcaca.png
[20210717091610286.png]: /images/20220829/0778cfb4cd3f43989f53d3f897df9295.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 32]: /images/20220829/8fb765f993aa495cb1637a18996fbfb0.png
[20210717091744620.png]: /images/20220829/65cb056f66484cb6af5283b41a2c3298.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 33]: /images/20220829/714ddf2f2945428ca167e049eb9e7d43.png
[20210717092833984.png]: /images/20220829/23c0e1243aca4764a5702921646262c7.png
[20210717092922583.png]: /images/20220829/d6b9322fafe446dca305901ecaac9b2f.png
[20210717093130527.png]: /images/20220829/02a9a56338944da68bb39d39838f5695.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 34]: /images/20220829/faf380c0c87345d9b4beb85298a0ba3a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 35]: /images/20220829/1ecf2e4328b548b38679d76f83515bcf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 36]: /images/20220829/2aa2943f08874986a09c1870cb8ab7a5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 37]: /images/20220829/bc4ec394ad0c4b84a7cee59668b08d28.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 38]: /images/20220829/83ba2370ccce4f47b401a4e5de772204.png
[20210718081716235.png]: /images/20220829/f9b33b5a85164bc19672622e590d31c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 39]: /images/20220829/bd93215a82514a2bbe8b62efb244094e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 40]: /images/20220829/ec7ebc9111944628810d019ae92d6c56.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 41]: /images/20220829/bcb0eb9a45b345259fd0451e1c0729ca.png
[20210718082516800.png]: /images/20220829/805191a1251143d59b1e5b520de6c081.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 42]: /images/20220829/71ccac72292c4e13b03411a158c6d6b8.png
[20210718083053149.png]: /images/20220829/35b776917c134d8481e66ae53189fa9d.png
[20210718083345489.png]: /images/20220829/9aab7c673f4b45ef84cf8ae08ed8036a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 43]: /images/20220829/36512efe727c43ada281d8f165e332fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 44]: /images/20220829/12b7b11f53e64cd8ba6afe321298cc57.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 45]: /images/20220829/0cf61d4c15724334bafb6be514ebf4ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 46]: /images/20220829/c924ec6d0c7d4a31b974bc8586b75603.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 47]: /images/20220829/e40fc9bbe2dd4d649f3b2378f837a5e4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 48]: /images/20220829/56f1aff23f0d45deace35149cb21324d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 49]: /images/20220829/ed21d5639be04eb395fa007bedb2c80c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 50]: /images/20220829/717a178f6f9f4bd8b2bdc234547139f8.png
[20210718091800747.png]: /images/20220829/4d55cdb7a89646a99f4c1a628228db36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 51]: /images/20220829/c6ab5cdc45b341ba83582300a8a2917b.png
[20210718092457224.png]: /images/20220829/59bf2a8c72234484bb20ef898fa177c9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 52]: /images/20220829/9b69dbd6e7c946069af3796ad3ec647d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 53]: /images/20220829/12c50cd4561b4aa28c975e6a8acd5a94.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 54]: /images/20220829/435ed1d3e13a43219d32b22bb279c75f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 55]: /images/20220829/6a759cf808c34b85a3389ebfdb2ff8f9.png
[20210718094258270.png]: /images/20220829/b7643a6312f64094a4c98bda5ec812b3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2dhb2ZlaTA0Mjg_size_16_color_FFFFFF_t_70 56]: /images/20220829/d9afdb6a03474ba7a05875c2736bf95e.png
[20210718094901509.png]: /images/20220829/40322971946648498df78b8bd2b43a5d.png
[20210718100806291.png]: /images/20220829/43a786d464d54e1d8ec09b382f82bc60.png