4 系统稳定性

1 日志分析常用命令

cat 适合日志文件比较少,不能分页
- -n参数显示行号
- image.png
more 支持分页
- Enter 下一行
- 空格下一页
- F 下一屏
- B 上一屏
less 支持分页，内容查找，高亮
- -N 显示行号
- Q 推出
- Shift + G 跳到最后
- /关键字向下搜索
- ?关键字向上搜索
- n 搜索后，前一个关键字
- N 搜索后，后一个关键字
- b 上一页
- 空格下一页
- d 下半页
- u 上半页
tail 显示文件尾
- -n 显示最后几行
- -f 持续显示文件新增的行
head 显示文件头
- -n 显示开头几行
wc 统计指定文件中的字符数、字数、行数，并输出统计结果
- -l 统计行
- -c 统计字节
- -L 显示最长的行长度
grep 字符串查找
- -c 计算符合样式的列数
- grep 11 access.log 查找指定符合查找字符串的行
find 文件查找
- -name 指定名称
- find /home -name "*.txt"
- 参考

1.1 日志分析脚本

sed编辑器
- sed [options] 'command' file(s)
  - command 为具体的文本编辑命令
  - file为输入的文件。
- -n 仅显示处理后的结果
- 动作说明
  - p 打印，亦即将某个选择的数据印出。通常 p 会与参数 sed -n 一起运行
  - sed -n '/开始时间日期/,/结束时间日期/p' spring.log
    - sed -n '/2020-09-02 08/,/2020-09-02 09/p' share-provider-isc.log
    - sed -n '/2020-09-02 08/,/2020-09-02 09/p' share-provider-isc.log | grep INFO

2 监控指标

2.1 load

定义特定时间间隔内运行队列中的平均线程数
- 每个CPU的核都维护了一个运行队列，系统的load主要由运行队列来决定
- 假设一个CPU有8个核，运行的应用程序启动了16个线程，并且这16个线程都处于运行状态，那么在平均分配的情况下，每个CPU的运行队列中就有2个线程在运行。假设这种情况维持了1分钟，那么这一分钟内的系统load值就为2
- load的值越大，也就意味着系统的CPU越繁忙，这样线程运行完以后等待操作系统分配下一个时间片段的时间也就越长
  - 一般来说，只要每个CPU当前的活动线程数不大于3，负载正常
  - 如果每个CPU的线程数大于5，则表示当前系统的负载已经非常高了
- load指的是所有核的平均值
  - 单核cpu的load=1表示系统一直处在负载状态，但是4核cpu的load=1表示系统有75%的空闲
uptime
- 13:05:49 系统当前时间
- up 44 days 表示系统最后一次启动后总的运行时间
- 2 users 当前系统中有两个登录用户
- load average: 5.84, 5.79, 5.72 系统的平均负载，1分钟，5分钟，15分钟的平均负载。

uptime
13:46:03 up 44 days, 19:22,  2 users,  load average: 5.84, 5.79, 5.72

top 指令参考

2.2 cpu 利用率

top | grep Cpu 命令查看
按1 查看每个核 cpu利用率
top –p 2864 -p 选项可以指定查看的进程
- CPU后面跟的各个列便是各种状态下CPU所消耗的时间占比
- us 用户时间表示CPU执行用户进程所占用的时间，通常情况下希望us的占比越高越好
- sy 系统时间示CPU在内核态所花费的时间，sy的占比较高，通常意味着系统在某些方面设计的不合理，比如频繁的系统调用导致的用户态与内核态的频繁切换。
- ni Nice时间表示系统在调整进程优先级的时候所花费的时间
- id 空闲时间表示系统处于空闲期，等待进程运行，这个过程所占用的时间。当然，我们希望id的占比越低越好。
- wa 等待时间表示CPU在等待I/O操作所花费的时间，系统不应花费大量的时间来进行等待，否则便表示可能有某个地方设计不合理
- is 硬件中断处理时间表示系统处理硬件中断所占用的时间
- si 软件中断处理时间示系统处理软件中断所占用的时间
- st 丢失时间是在硬件虚拟化开始流行后操作系统新增的一列，表示被强制等待虚拟CPU的时间

top | grep Cpu
%Cpu(s): 19.4 us,  7.2 sy,  0.0 ni, 73.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu(s): 11.6 us,  3.3 sy,  0.0 ni, 84.7 id,  0.3 wa,  0.0 hi,  0.1 si,  0.0 st

2.3 磁盘剩余空间

df -h

df -h
文件系统                          容量  已用  可用 已用% 挂载点
/dev/mapper/cl_docker--temp-root  3.7T  1.5T  2.3T   39% /
devtmpfs                           63G     0   63G    0% /dev
tmpfs                              63G     0   63G    0% /dev/shm
tmpfs                              63G  955M   62G    2% /run
tmpfs                              63G     0   63G    0% /sys/fs/cgroup
/dev/sda1                        1014M  264M  751M   26% /boot
/dev/mapper/cl_docker--temp-home  5.0G   33M  5.0G    1% /home

du -d 1 -h /home
- -d 递归深度 1 表示指定目录下一级目录
- -h 按文件大小单位的格式化输出

# du -d 1 -h /home
12K     /home/test
12K     /home/test2
24K     /home

2.4 网络traffic 关注网络的流量，清楚各个节点的阈值和水位

sar -n DEV 1 1
- -n 汇报网络状况
- DEV 查看各个网卡的网络流量
- 1 表示1s抽取一次，第二个1总共抽取一次

 sar -n DEV 1 1
Linux 3.10.0-957.10.1.el7.x86_64 (docker-temp)  2020年09月22日  _x86_64_        (16 CPU)

14时16分56秒     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
14时16分57秒 vethf141128      0.00      0.00      0.00      0.00      0.00      0.00      0.00
14时16分57秒 vethe06a4e8      0.00      0.00      0.00      0.00      0.00      0.00      0.00
14时16分57秒 veth093cd59      0.00      0.00      0.00      0.00      0.00      0.00      0.00
14时16分57秒 vethf018391      0.00      0.00      0.00      0.00      0.00      0.00      0.00
14时16分57秒 vethd6c0573      1.00      1.00      0.07      0.05      0.00      0.00      0.00
14时16分57秒 veth36e24fe      0.00      0.00      0.00      0.00      0.00      0.00      0.00

IFACE 网卡 lo是本地回环网络
rxpck/s 每秒接收的数据包数量
txpck/s 每秒发出的数据包数量
rxkB/s 每秒接收到的字节数（KB）
txkB/s 表示的是每秒发送的字节数（KB）
rxcmp/s 表示每秒收到的压缩包的数量
txcmp/s 每秒发送的压缩包的数量
rxmcst/s 每秒收到的广播包的数量

2.5 磁盘I/O

对于I/O密集型的应用来说，比如数据库应用和分布式文件系统等，I/O的繁忙程度也一定程度地反映了系统的负载情况，容易成为应用性能的瓶颈。
iostat -d -k
- -d选项表示查看磁盘使用情况
- -k选项表示以KB为单位显示

iostat -d -k
Linux 3.10.0-957.10.1.el7.x86_64 (docker-temp)  2020年09月22日  _x86_64_        (16 CPU)

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             136.27       708.67      1560.08 2745167173 6043292329
scd0              0.00         0.00         0.00       1028          0
dm-0            201.44       708.66      1560.08 2745125602 6043288082
dm-1              0.00         0.00         0.00       2456          0
dm-2              0.00         0.00         0.00       1513       2138

Device 设备名称
tps 每秒处理的I/O请求数
kB_read/s 每秒从设备读取的数据量
kB_wrtn/s 每秒向设备写入的数据量
kB_read 读取的数据总量
kB_wrtn 写入的数据总量

2.6 内存使用

程序运行时的数据加载、线程并发、I/O缓冲等，都依赖于内存，可用内存的大小决定了程序是否能正常运行以及运行的性能。
free -m 参考
- -m 以mb为单位显示

free -h
              total        used        free      shared  buff/cache   available
Mem:           125G        110G        1.5G        684M         13G         13G
Swap:          257G         57G        200G

total 内存总共的大小
used 已使用内存的大小
free 可使用的内存大小
shared 多个进程共享的内存空间大小
buff/cache 列显示被 buffer 和 cache 使用的物理内存大小
available 还可以被应用程序使用的物理内存大小
Linux 其中有一个思想便是内存利用率最大化，内核会将剩余的内存申请为cached，而cached不属于free范畴。因此，当系统运行时间较长时，会发现cached这块区域比较大，对于有频繁文件读/写操作的系统，这种现象更加明显
free的内存小，并不代表可用的内存小，当程序需要申请更大的内存时，如果free内存不够，系统会将部分cached或buffers内存回收，回收的内存再分配给应用程序。因此，Linux可用于分配的内存不仅仅只有free的内存。可看free命令显示的第三行，也就是-/+ buffers/cache对应的行
对于应用来说，更值得关注的应该是虚拟内存swap的消耗
- swap内存使用过多，表示物理内存已经不够用了.
- 操作系统将本应该物理内存存储的一部分内存页调度到磁盘上，以腾出足够的空间给当前的进程使用。当其他进程需要运行时，再从磁盘将内存的页调度到物理内存当中，以恢复进程的运行。而这个调度的过程，则会产生swap I/O，如果swap I/O较为频繁，将严重地影响系统的性能。
vmstat命令，可以查看到swap I/O的情况参考

vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 7  0 60982964 959440      0 14354452    8    9    45    99    0    0 25  5 68  1  0

r 运行队列中进程数量，这个值也可以判断是否需要增加CPU
b 等待IO的进程数量。
swpd 虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了
free 空闲物理内存大小。
buff 用作缓冲的内存大小。
cache 用作缓存的内存大小，如果cache的值大的时候，说明cache处的文件数多，如果频繁访问到的文件都能被cache处，那么磁盘的读IO bi会非常小。
si 每秒从交换区写到内存的大小，由磁盘调入内存。
so 每秒写入交换区的内存大小，由内存调入磁盘。
bi 每秒读取的块数
bo 每秒写入的块数
in 每秒中断数，包括时钟中断。
cs 每秒上下文切换数。
us 用户进程执行时间百分比(user time)
sy 内核系统进程执行时间百分比(system time)
wa IO等待时间百分比
id 空闲时间百分比

3 性能优化

3.1 前端 YSlow 网页性能分析的浏览器插件

外加firebug 定位到哪个请求很慢
前端优化
- 页面的HTTP请求数量。
  - 减少HTTP请求的数量能够加速页面的加载，在不改变页面外观的情况下，可以通过采取合并样式和脚本文件等措施，来减少页面加载所需要请求数
- 是否使用CDN网络
- 是否使用压缩。

3.2 方法响应时间

3.2.1 测试环境可以重现用StopWatch 测试具体是哪个步骤耗时进行优化

    @Test
    public void testStopWatch() throws InterruptedException {
        StopWatch stopWatch = new StopWatch();
        stopWatch.start("测试1");
        Thread.sleep(1000);
        stopWatch.stop();
        stopWatch.start("测试2");
        Thread.sleep(200);
        stopWatch.stop();
        System.out.println(stopWatch.prettyPrint());

    }
// 输出
StopWatch '': running time = 1199763500 ns
---------------------------------------------
ns         %     Task name
---------------------------------------------
1000120600  083%  测试1
199642900  017%  测试2

3.2.2 测试环境不能重新，btrace 进行调试

下载
配置环境变量

#1, BTRACE_HOME
BTRACE_HOME D:\softwareStudy\btrace2.0\btrace-bin

#2, path 加
%BTRACE_HOME%\bin

# 测试
C:\Users\weepal>btrace --version
BTrace v.2.0.0 (15dcb82b539b4c6fab72b01da8ead18a5b8f71a0)

BTrace的用法
btrace [-I ] [-p ] [-cp ] [ ]
- -I BTrace支持对#define、#include这样的条件编译指令进行简单的处理，include-path用来指定这样的头文件目录；
- -p port参数用来指定btrace agent端口，默认是2020；
- -cp classpath用来指定编译所需类路径，一般是指btrace-client.jar等类所在路径；
- pid—需要跟踪的Java进程id；
- btrace-script—自定义的 btrace脚本；
- args—传递给btrace脚本的参数。
假如查看 /djgCertuser/loginCertsn 耗时

@BTrace
public class BtraceTimeTest {
    @TLS private static long startTime = 0;

    @OnMethod(
            clazz="com.wp.ecs.controller.login.DjgLoginRelatedController",
            method="codeLogin",location = @Location(Kind.ENTRY)
    )
    public static void start() {
        startTime = timeMillis();
    }


    @OnMethod(
            clazz = "com.wp.ecs.controller.login.DjgLoginRelatedController",
            method = "codeLogin",
            location = @Location(Kind.RETURN)
    )
    public static void end(@ProbeClassName String pcn,
                               @ProbeMethodName String pmn,
                               AnyType[] args
    ) {
        long timecost = timeMillis() - startTime;
        println(Strings.strcat("time taken : ",str(timecost)));
        printArray(args);
    }
}

# 输出
time taken : 246
[com.wp.ecs.filter.AesKeyAllWrapper@3953e8d, 21312, 10816A7EDADAE81ADC6E21, 2, ]

基本用法

3.2.3 Java程序优化

找到执行速度慢的Java方法后，就需要想办法对原有的设计进行优化如
- 单例模式
  - 对于I/O处理、数据库连接、配置文件解析加载等一些非常耗费系统资源的操作，我们必须对这些实例的创建进行限制，或者始终使用一个公用的实例，以节约系统开销
- 减少系统开销
- 将单线程变为多线程
- 提升资源利用率
- 采用选择就绪模式
- 提高并发吞吐
- 对于不相互影响的流程，可以使用Future模式来提升任务效率
- 减少上下文切换。
- 降低锁竞争。
- 压缩如有必要时对cookie进行，然后转base64

3.2.4 GC优化

通过GC日志能够看出一些端倪，包括Minor GC的频率、Full GC的频率、GC导致的停顿时间及GC发生的原因等。可以通过这些信息来解决GC所导致的一些问题，以及对应用性能进行优化
查看gc日志

#堆初始大小
-Xms10880M
#堆最大值
-Xmx10880M
#输出GC相关信息
 -verbose:gc 
 #指定GC日志
 -Xloggc:F:\company\公司项目\ECS2\trunk\ECS2\logs\gc.log 
 #输出GC详情
 -XX:+PrintGCDetails
 #日志中会输出GC的时间戳 会多打印gc发生时间
 -XX:+PrintGCDateStamps
 #发生内存溢出时自动的生成堆内存快照
 -XX:+HeapDumpOnOutOfMemoryError
 #生成堆内存快照路径
 -XX:HeapDumpPath=F:\company\公司项目\ECS2\trunk\ECS2\logs
 #使用Parallel Scavenge + Parallel Old，追求吞吐量的的最佳配合
-XX:+UseParallelOldGC

正式服务器常用垃圾收集器组合
-XX:+UseParallelOldGC
- Parallel Scavenge + Parallel Old组合
- 一些系统任务，追求吞吐量的的最佳配合
-XX:+UseConcMarkSweepGC
- ParNew+CMS+Serial Old 组合
- g1与cms都是追求最短停顿时间，cms牺牲吞吐量获得最短停顿时间，相对g1 适合堆很大的，jdk7cms更加适合
-XX:+UseG1GC g1收集器
- jdk8 并且堆不是特点大使用他。
初始调优
- 调整堆的初始大小
  - -xms10m -xmx100m,
  - 一个经验法则是完成 Full GC 后，应该释放出 70% 的空间（30% 的空间仍然占用）
- 调整青年代，老年代大小
  - jvm参数
    - -XX:NewRatio=N 老年代与新生代比例默认2 青年代 1/3
    - -XX:NewSize=N 设置新生代空间的初始大小。
    - -XX:MaxNewSize=N 设置新生代空间的最大大小。
    - -XmnN 将 NewSize 和 MaxNewSize 设定为同一个值
- 永久代和元空间的调整
  - -XX:PermSize=N
  - -XX:MaxPermSize=N
  - -XX:MetaspaceSize=N
  - -XX:MaxMetaspaceSize=N
- 控制并发调整线程数量
- cms concurrent mode failure
  - 并发标记预留的内存无法满足程序需要则会出现concurrent mode failure
    - -XX:CMSInitiatingOccupancyFraction=68 默认68 可以适当降低这个值
      - 表示当OldGen使用了68%的时候，CMS收集会被激活
参考大型分布式网站架构设计与实践

4 系统稳定性

1 日志分析常用命令

1.1 日志分析脚本

2 监控指标

2.1 load

2.2 cpu 利用率

2.3 磁盘剩余空间

2.4 网络traffic 关注网络的流量，清楚各个节点的阈值和水位

2.5 磁盘I/O

2.6 内存使用

3 性能优化

3.1 前端 YSlow 网页性能分析的浏览器插件

3.2 方法响应时间

3.2.1 测试环境可以重现 用StopWatch 测试具体是哪个步骤耗时进行优化

3.2.2 测试环境不能重新，btrace 进行调试

3.2.3 Java程序优化

3.2.4 GC优化

你可能感兴趣的:(4 系统稳定性)

3.2.1 测试环境可以重现用StopWatch 测试具体是哪个步骤耗时进行优化