什么是平均负载

  1. [root@111 ~]# uptime
  2.  11:03:33 up 149 days, 17:34,  1 user,  load average: 0.08, 0.05, 0.01

最后三个数字，依次则是过去1分钟、5分钟、15分钟的平均负载（Load Average），常用的top工具也能展示

平均负载作为极其重要的系统指标，是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和CPU使用率并没有直接关系。

可运行状态的进程，是指正在使用CPU或者正在等待CPU的进程，也就是我们常用ps命令看到的，处于R状态（Running 或 Runnable）的进程。

不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的I/O响应，也就是我们在ps命令中看到的D状态（Uninterruptible Sleep）的进程。

比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。

所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

综上所述，平均负载其实就是平均活跃进程数，即单位时间内的活跃进程数。

平均负载为多少时合理

最理想的状态，是每个CPU上都刚好跑着一个进程，这样每个CPU都得到了充分利用。比如当平均负载为2时，意味着什么呢？

  • 在只有2个CPU的系统上，意味着所有的CPU都刚好被完全占用。

  • 在4个CPU的系统上，意味着CPU有50%的空闲。

  • 而在只有1个CPU的系统中，则意味着有一半的进程竞争不到CPU。

所以，平均负载最理想的情况是等于 CPU个数。在评判平均负载时，首先要知道系统有几个 CPU，可以通过 top 命令或者从文件 /proc/cpuinfo 中读取，比如：

  1. 逻辑cpu个数：
  2. [root@111 ~]# grep processor /proc/cpuinfo |wc -l
  3. 4

一般来说，实际生产环境中，当平均负载为 CPU 数量的70-80%的时候，就应该分析排查负载高的问题了。

另一方面，我们需要关注平均负载三个数值的变化：

  • 如果1分钟、5分钟、15分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。

  • 但如果1分钟的值远小于15 分钟的值，就说明系统最近1分钟的负载在减少，而过去15分钟内却有很大的负载。

  • 反过来，如果1分钟的值远大于 15 分钟的值，就说明最近1分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦1分钟的平均负载接近或超过了CPU的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。

举个栗子，4核的机子，平均负载为 3.23，1.60，6.98：

  • 在过去的15分钟，平均负载超过cpu个数，说明负载很高，可能是cpu使用率很高，也可能是I/O的压力等等原因。
  • 过去1分钟和过去5分钟，平均负载都小于cpu个数，说明负载正常，从整体趋势来看，系统的负载在降低，但是过去1分钟的值大于过去5分钟的值，说明平均负载又在升高。

70-80%这个数字并不是绝对的，毕竟最长的15分钟的数据也只是短期的表现，最推荐的方法，是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的整体变化趋势。

平均负载与CPU使用率

现实工作中，我们经常容易把平均负载和 CPU 使用率混淆，其实两者还是有区别的。

可能你会疑惑，既然平均负载代表的是活跃进程数，那平均负载高了，不就意味着 CPU 使用率高吗？

我们还是要回到平均负载的含义上来，平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待 I/O 的进程。

CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。比如：

  • CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；

  • I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；

  • 大量等待 CPU 的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高。

平均负载案例模拟分析

模拟三个场景分别来看以上三种情况，使用iostat、mpstat、pidstat 等工具，找出平均负载升高的根源。

  • 机器配置：4cpu，16G内存，centos
  • 安装 stress 和 sysstat 工具包，yum install stress sysstat -y

stress 是一个 Linux 系统压力测试工具

  1. stress语法格式：
  2. stress <options>
  3.  
  4. 常用选项：
  5. -c, --cpu N              产生 N 个进程，每个进程都反复不停的计算随机数的平方根
  6. -i, --io N               产生 N 个进程，每个进程反复调用 sync() 将内存上的内容写到硬盘上
  7. -m, --vm N               产生 N 个进程，每个进程不断分配和释放内存
  8.     --vm-bytes B         指定分配内存的大小
  9.     --vm-stride B        不断的给部分内存赋值，让 COW(Copy On Write)发生
  10.     --vm-hang N          指示每个消耗内存的进程在分配到内存后转入睡眠状态 N 秒，然后释放内存，一直重复执行这个过程
  11.     --vm-keep            一直占用内存，区别于不断的释放和重新分配(默认是不断释放并重新分配内存)
  12. -d, --hadd N             产生 N 个不断执行 write 和 unlink 函数的进程(创建文件，写入内容，删除文件)
  13.     --hadd-bytes B       指定文件大小
  14. -t, --timeout N          在 N 秒后结束程序
  15. --backoff N              等待N微妙后开始运行
  16. -q, --quiet              程序在运行的过程中不输出信息
  17. -n, --dry-run            输出程序会做什么而并不实际执行相关的操作
  18. --version                显示版本号
  19. -v, --verbose            显示详细的信息

sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能，主要包括：

  1. iostat 工具提供CPU使用率及硬盘吞吐效率的数据；  #比较核心的工具
  2. mpstat 工具提供单个处理器或多个处理器相关数据；
  3. pidstat: 关于运行中的进程/任务、CPU、内存等的统计信息
  4. sar 工具负责收集、报告并存储系统活跃的信息；    #统计数据的核心工具
  5. sa1 工具负责收集并存储每天系统动态信息到一个二进制的文件中。它是通过计划任务工具cron来运行，是为sadc所设计的程序前端程序；
  6. sa2工具负责把每天的系统活跃性息写入总结性的报告中。它是为sar所设计的前端 ，要通过cron来调用
  7. sadc 是系统动态数据收集工具，收集的数据被写一个二进制的文件中，它被用作sar工具的后端；
  8. sadf 显示被sar通过多种格式收集的数据；
  9. nfsiostat: NFS（Network File System）的I/O统计信息。
  10. cifsiostat: CIFS(Common Internet File System)的统计信息。

每个场景都需要开三个终端，登录到同一台 Linux 机器中，使用uptime看一下测试前的平均负载：

  1. [root@123~]# uptime
  2.  16:11:04 up 150 days, 22:42,  3 users,  load average: 0.06, 0.03, 0.00

场景一：CPU 密集型进程

首先，在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：

  1. #产生1个进程反复不停的计算随机数的平方根，300秒后停止
  2. [root@123 ~]# stress -c 1 -t 300

接着，在第二个终端运行watch -d uptime查看平均负载的变化情况：

  1. # -d 参数表示高亮显示变化的区域
    Every 2.0s: uptime 
  2. 16:26:55 up 150 days, 22:58,  3 users,  load average: 1.05, 0.76, 0.40

可以看到，1 分钟的平均负载会慢慢增加到 1.00出头

最后，在第三个终端运行mpstat查看 CPU 使用率的变化情况：

  1. mpstat --help
  2. 用法: mpstat [ 选项 ] [ <时间间隔> [ <次数> ] ]
  3. 选项：
  4. [ -I { SUM | CPU | SCPU | ALL } ] [ -N { <node_list> | ALL } ]
  5. [ --dec={ 0 | 1 | 2 } ] [ -o JSON ] [ -P { <CPU_列表> | ALL } ]
  6.  
  7. #-P ALL 表示监控所有CPU，间隔5秒后输出一组数据，总计5组
  8. [root@123~]# mpstat -P ALL 5 5
  9.  
  10. 04:25:28 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
  11. 04:25:33 PM  all   25.11    0.00    0.20    0.35    0.00    0.00    0.00    0.00   74.34
  12. 04:25:33 PM    0    0.40    0.00    0.20    0.00    0.00    0.00    0.00    0.00   99.40
  13. 04:25:33 PM    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
  14. 04:25:33 PM    2    0.00    0.00    0.60    1.60    0.00    0.00    0.00    0.00   97.80
  15. 04:25:33 PM    3    0.00    0.00    0.20    0.00    0.00    0.00    0.00    0.00   99.80
  16.  
  17. 04:25:33 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
  18. 04:25:38 PM  all   25.13    0.00    0.15    0.40    0.00    0.00    0.00    0.00   74.32
  19. 04:25:38 PM    0    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
  20. 04:25:38 PM    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
  21. 04:25:38 PM    2    0.20    0.00    0.40    1.41    0.00    0.00    0.00    0.00   97.99
  22. 04:25:38 PM    3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100%

那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？可以使用 pidstat 来查询：

  1. pidstat --help
  2. 用法：pidstat [ 选项 ] [ <时间间隔> [ <计数> ] ] [ -e <程序> <参数> ]
  3. 选项：
  4. [ -d ] [ -H ] [ -h ] [ -I ] [ -l ] [ -R ] [ -r ] [ -s ] [ -t ] [ -U [ <用户名> ] ]
  5. [ -u ] [ -V ] [ -v ] [ -w ] [ -C <命令> ] [ -G <进程名> ]
  6. [ -p { <pid> [,...] | SELF | ALL } ] [ -T { TASK | CHILD | ALL } ]
  7. [ --dec={ 0 | 1 | 2 } ] [ --human ]
  8. 常用选项解释：
  9. -u：默认的参数，显示各个进程的cpu使用统计
  10. -r：显示各个进程的内存使用统计
  11. -d：显示各个进程的IO使用情况
  12. -p：指定进程号
  13. -w：显示每个进程的上下文切换情况
  14.  
  15. #间隔5秒输出一组数据，总计5组
  16. [root@123 ~]# pidstat -u 5 5
  17.  
  18. 04:26:17 PM       PID    %usr %system  %guest    %CPU   CPU  Command
  19. 04:26:22 PM      2464    0.20    0.00    0.00    0.20     3  netdata
  20. 04:26:22 PM      2677    0.20    0.00    0.00    0.20     0  python
  21. 04:26:22 PM     26629    0.00    0.40    0.00    0.40     2  apps.plugin
  22. 04:26:22 PM     28735  100.00    0.00    0.00  100.00     3  stress
  23.  
  24. 04:26:22 PM       PID    %usr %system  %guest    %CPU   CPU  Command
  25. 04:26:27 PM      2464    0.20    0.00    0.00    0.20     3  netdata
  26. 04:26:27 PM     26629    0.20    0.20    0.00    0.40     2  apps.plugin
  27. 04:26:27 PM     28735  100.00    0.00    0.00  100.00     3  stress

从这里可以明显看到，stress进程的CPU使用率为100%。

场景二：I/O 密集型进程

首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync：

  1. # 产生1个进程，反复调用 sync() 将内存上的内容写到硬盘上，300秒后结束
  2. [root@123~]# stress -i 1 -t 300

还是在第二个终端运行watch -d uptime查看平均负载的变化情况：

  1. 17:14:02 up 150 days, 23:45,  4 users,  load average: 1.52, 1.68, 0.80

可以看到，平均负载再次上升

然后，第三个终端运行mpstat查看 CPU 使用率的变化情况：

  1. #显示所有CPU的指标，间隔5秒输出一组数据，持续输出
  2. [root@123 ~]# mpstat -P ALL 5
  3. 05:08:10 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
  4. 05:08:15 PM  all    0.15    0.00    0.15    0.20    0.00    0.00    0.00    0.00   99.50
  5. 05:08:15 PM    0    0.20    0.00    0.20    0.00    0.00    0.00    0.00    0.00   99.60
  6. 05:08:15 PM    1    0.20    0.00    0.40    0.00    0.00    0.00    0.00    0.00   99.40
  7. 05:08:15 PM    2    0.20    0.00    0.00    1.00    0.00    0.00    0.00    0.00   98.80
  8. 05:08:15 PM    3    0.20    0.00    0.20    0.00    0.00    0.00    0.00    0.00   99.60
  9.  
  10. 05:08:15 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
  11. 05:08:20 PM  all    0.15    0.00    0.20   10.67    0.00    0.00    0.00    0.00   88.98
  12. 05:08:20 PM    0    0.20    0.00    0.00   14.63    0.00    0.00    0.00    0.00   85.17
  13. 05:08:20 PM    1    0.00    0.00    0.40    0.00    0.00    0.00    0.00    0.00   99.60
  14. 05:08:20 PM    2    0.00    0.00    0.20   28.11    0.00    0.00    0.00    0.00   71.69
  15. 05:08:20 PM    3    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.80
  16.  
  17. 05:08:20 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
  18. 05:08:25 PM  all    0.15    0.00    0.20   22.19    0.00    0.00    0.00    0.00   77.45
  19. 05:08:25 PM    0    0.20    0.00    0.20   29.46    0.00    0.00    0.00    0.00   70.14
  20. 05:08:25 PM    1    0.20    0.00    0.40    0.00    0.00    0.00    0.00    0.00   99.40
  21. 05:08:25 PM    2    0.20    0.00    0.20   59.44    0.00    0.00    0.00    0.00   40.16
  22. 05:08:25 PM    3    0.20    0.00    0.20    0.00    0.00    0.00    0.00    0.00   99.60

可以发现，系统CPU使用率很低，而 iowait很高，其中一个高达 59.44%，这说明平均负载的升高是由于 iowait 的升高。

是哪个进程导致iowait这么高？

  1. #pidstat -d：显示各个进程的IO使用情况
  1. [root@123 ~]# pidstat -d 3 3
  2.  
  3. 05:12:56 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
  4. 05:12:59 PM       701      0.00     68.00      0.00  jbd2/dm-0-8
  5. 05:12:59 PM      1518      0.00    292.00      0.00  flush-253:0
  6. 05:12:59 PM      1968      0.00     28.00      0.00  java
  7.  
  8. 05:12:59 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
  9. 05:13:02 PM       701      0.00     80.00      0.00  jbd2/dm-0-8
  10. 05:13:02 PM      1518      0.00    268.00      0.00  flush-253:0
  11. 05:13:02 PM      1968      0.00     30.67      0.00  java
  12.  
  13. 05:13:02 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
  14. 05:13:05 PM       701      0.00     80.00      0.00  jbd2/dm-0-8
  15. 05:13:05 PM      1518      0.00    286.67      0.00  flush-253:0
  16. 05:13:05 PM      1968      0.00     36.00      0.00  java

jbd2/dm-0-8和flush-253:0都是操作系统针对磁盘和文件系统的进程，本质上是stress 进程导致的，因为300秒后当stress结束了，这两个进程也结束了。

场景三：大量进程的场景

当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。

比如，我们还是使用 stress，但这次模拟的是 8 个进程：

  1. [root@123 ~]# stress -c 8 -t 300

由于系统只有 4 个CPU，比 8 个进程要少一半，因而，系统的 CPU 处于严重过载状态，平均负载高达7.90：

  1. 11:35:53 up 155 days, 18:07,  4 users,  load average: 7.90, 5.51, 3.00

使用mpstat查看cpu使用率

  1. [root@123~]# mpstat -P ALL 3 10
  2.  
  3. 11:30:17 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
  4. 11:30:20 AM  all   99.83    0.00    0.17    0.00    0.00    0.00    0.00    0.00    0.00
  5. 11:30:20 AM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
  6. 11:30:20 AM    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
  7. 11:30:20 AM    2  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
  8. 11:30:20 AM    3   99.67    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00
  9.  
  10. 11:30:20 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
  11. 11:30:23 AM  all   99.92    0.00    0.08    0.00    0.00    0.00    0.00    0.00    0.00
  12. 11:30:23 AM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
  13. 11:30:23 AM    1   99.67    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00
  14. 11:30:23 AM    2   99.67    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00
  15. 11:30:23 AM    3  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00

可见4个cpu都被打满，再用pidstat看一下进程使用cpu的情况：

  1. [root@123 ~]# pidstat 3 10
  2.  
  3. 11:30:20 AM       PID    %usr %system  %guest    %CPU   CPU  Command
  4. 11:30:23 AM      2385    0.33    0.00    0.00    0.33     2  java
  5. 11:30:23 AM      2464    0.33    0.33    0.00    0.66     0  netdata
  6. 11:30:23 AM     26384   49.67    0.00    0.00   49.67     1  stress
  7. 11:30:23 AM     26385   49.67    0.00    0.00   49.67     0  stress
  8. 11:30:23 AM     26386   49.01    0.00    0.00   49.01     3  stress
  9. 11:30:23 AM     26387   49.67    0.00    0.00   49.67     2  stress
  10. 11:30:23 AM     26388   50.66    0.00    0.00   50.66     3  stress
  11. 11:30:23 AM     26389   49.67    0.00    0.00   49.67     0  stress
  12. 11:30:23 AM     26390   49.67    0.00    0.00   49.67     1  stress
  13. 11:30:23 AM     26391   49.67    0.00    0.00   49.67     2  stress
  14.  
  15. 11:30:23 AM       PID    %usr %system  %guest    %CPU   CPU  Command
  16. 11:30:26 AM     26223    0.33    0.00    0.00    0.33     3  watch
  17. 11:30:26 AM     26384   49.67    0.00    0.00   49.67     1  stress
  18. 11:30:26 AM     26385   50.00    0.00    0.00   50.00     0  stress
  19. 11:30:26 AM     26386   50.00    0.00    0.00   50.00     3  stress
  20. 11:30:26 AM     26387   50.00    0.00    0.00   50.00     2  stress
  21. 11:30:26 AM     26388   49.67    0.00    0.00   49.67     3  stress
  22. 11:30:26 AM     26389   50.00    0.00    0.00   50.00     0  stress
  23. 11:30:26 AM     26390   50.00    0.00    0.00   50.00     1  stress
  24. 11:30:26 AM     26391   50.00    0.00    0.00   50.00     2  stress
  25. 11:30:26 AM     26524    0.00    0.33    0.00    0.33     2  pidstat

可以看出，8 个stress进程在争抢 4 个 CPU，每个进程都占据着0.5个cpu，同时等待 CPU 的时间也是 50%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。

小结

分析完这三个案例，归纳一下平均负载的理解。

平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时，也要注意：

  • 平均负载高有可能是 CPU 密集型进程导致的；

  • 平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；

  • 当发现负载高的时候，你可以使用 mpstat、pidstat 等工具，辅助分析负载的来源。

linux之平均负载（学习笔记非原创）的更多相关文章

  1. Java Interface 是常量存放的最佳地点吗？（转帖学习，非原创）

    Java Interface 是常量存放的最佳地点吗?(转帖学习,非原创) 由于java interface中声明的字段在编译时会自动加上static final的修饰符,即声明为常量.因而inter ...

  2. Linux——帮助命令简单学习笔记

    Linux帮助命令简单学习笔记: 一: 命令名称:man 命令英文原意:manual 命令所在路径:/usr/bin/man 执行权限:所有用户 语法:man [命令或配置文件] 功能描述:获得帮助信 ...

  3. 理解 Linux 的平均负载和性能监控

      在本文中,我们将解释 Linux 系统中最关键的管理任务之一——关于系统 / CPU 的负载load和平均负载Load average的性能监控. 首先来看所有的类 UNIX 系统中两个重要的表述 ...

  4. Linux性能优化实战学习笔记：第四讲

    一.怎么查看系统上下文切换情况 通过前面学习我么你知道,过多的上下文切换,会把CPU时间消耗在寄存器.内核栈以及虚拟内存等数据的保存和回复上,缩短进程真正运行的时间,成了系统性能大幅下降的一个元凶 既 ...

  5. 【转】Linux系统平均负载3个数字的含义

    文章作者:姜南(Slyar) 文章来源:Slyar Home (www.slyar.com) 转载请注明,谢谢合作. 越来越多人开始接触Linux操作系统,从VPS到无线路由的刷机系统(如OpenWR ...

  6. 高性能MySQL--索引学习笔记（原创）

    看过一些人写的学习笔记,完全按书一字不漏照抄,内容很多,真不能叫笔记.遂自己整理了一份,取其精要. 更多笔记请访问@个人简书 [toc] 索引概述 索引即key 在存储引擎层实现,不同引擎工作方式不同 ...

  7. Linux系统平均负载3个数字的含义

    越来越多人开始接触Linux操作系统,从VPS到无线路由的刷机系统(如OpenWRT.Tomato),同时也必不可少地会在各式各样的探针和系统监测界面上看到"系统平均负载"或者&q ...

  8. Linux性能优化实战学习笔记：第五讲

    一.什么是CPU的使用率 1.你最常用什么指标来描述系统的CPU性能? 我想你的答案,可能不是平均负载,也不是CPU上下文切换,而是另一个更直观的指标CPU使用率 CPU使用率到底是怎么算出来的吗? ...

  9. Linux性能优化实战学习笔记：第七讲

    一.进程的状态 1.命令查看 top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28961 root 20 0 43816 3148 ...

随机推荐

  1. 关于获取客户端IP问题

    //相关代码 1.HttpContext.Current.Request.ServerVariables["HTTP_X_FORWARDED_FOR"] 2.HttpContext ...

  2. Android开源项目分类汇总-转载

    太长了,还是转载吧...今天在看博客的时候,无意中发现了@Trinea在GitHub上的一个项目Android开源项目分类汇总,由于类容太多了,我没有一个个完整地看完,但是里面介绍的开源项目都非常有参 ...

  3. MySQL 5.7.29安装配置

    一.环境准备(关闭防火墙) 1.清除已安装数据库 [root@mysql01 ~]# rpm -qa | grep mariadb mariadb-libs-5.5.35-3.el7.x86_64 [ ...

  4. 密码管理平台ratticdb的部署，在centos7上的部署

    一,前言 一直想用ratticdb这个有web界面的密码管理工具,百度了一下居然没有找到中文的部署文档,访问官网也是notfound.找到了官方的部署指南:https://github.com/til ...

  5. ubuntu 设置apple主题

    ubuntu 设置apple主题 参考地址,主要是看这个,很详细 https://linuxhint.com/gnome-tweak-tool-ubuntu-17-10/ 效果图 终端命令 $ sud ...

  6. windows上mysql5.7服务启动报错

    安装之后,启动服务 net start mysql,无法启动,日志报错缺少一些系统表,mysql.user等表 解决办法: bin目下执行:mysqld --initialize-insecure - ...

  7. react第四单元(ref与DOM-findDomNode-unmountComponentAtNode)

    第四单元(ref与DOM-findDomNode-unmountComponentAtNode) #课程目标 理解react的框架使用中,真实dom存在的意义. 使用真实dom和使用虚拟dom的场景. ...

  8. Tomcat9没有service.bat

    下载个Windows版本的才有service.bat,默认是不带的. 附上tomcat9的下载地址: https://archive.apache.org/dist/tomcat/tomcat-9/v ...

  9. WP | [MRCTF2020]Ezpop

    2020.10.14 最近开始努力提高代码能力 题目代码 Welcome to index.php <?php //flag is in flag.php //WTF IS THIS? //Le ...

  10. kali docker简单使用-vulhub搭建fastjson漏洞环境

    准备环境 安装kali和docker参考: https://www.cnblogs.com/lijingrong/p/13396884.html sudo service docker start / ...