概述
什么是性能？
性能最通俗的衡量指标就是“时间”，CPU的使用率指的是CPU用于计算的时间占比，磁盘使用率指的是磁盘操作的时间占比。
当CPU使用率100%时，意味着有部分请求来不及计算，响应时间增加或者超时；
当磁盘使用率100%时，意味着有部分请求需要等待IO操作，响应时间也会增加或者超时。
换言之，所有的操作都在理想的时间内，就不存在“性能优化“的问题。我们在分析性能的时候，总是会首先要找到是什么引起响应时间变慢了，对应单机性能的分析，一般我们会将目光锁定在CPU和IO上，因为对于应用程序一般分为CPU bound型和IO。
bound型，即计算密集型或者读写密集型；至于内存，其性能因素往往也会反映到CPU或者IO上，因为内存的设计初衷就是提高内核指令和应用程序的读写性能。
当内存不足，系统可能进行大量的交换操作，这时候磁盘可能成为瓶颈；而缺页、内存分配、释放、复制、内存地址空间映射等等问题又可能引起CPU的瓶颈；更严重的情况是直接影响功能，这个就不仅仅是性能的问题了。
性能优化并不是一个孤立的课题，除了响应时间的考虑，我们往往还需要综合功能完整性、安全性等等方面的问题。
性能分析的基础
性能优化需要厚实的基础知识：
- 操作系统
操作系统管理着应用程序所需要的所有资源，例如CPU和IO，当任何一个组件出现问题，我们的分析也是基于操作系统的，例如文件系统类型，磁盘类型，磁盘raid类型都需要操作系统管理和支持。 - 系统编程技术
系统编程技术涉及到我们如何使用系统资源，例如对IO的操作我们可以使用buffering I/O，也可以使用Direct IO，可以采用同步的方式，也可以采用异步的方式，可以使用多进程，也可以使用多线程的方式。懂得不同编程技术的原理，有利于问题的分析。 - 应用程序
例如数据库组件的数据类型、引擎、索引、复制、配置参数、备份、高可用等等都可能是性能问题的元凶。
性能分析的方法论
问题分析方面，各类方法论如金字塔思维、5W2H、麦肯锡七步法等等。套用5W2H方法，可以提出性能分析的几个问题
- What-现象的表现是什么样的
- When-什么时候发生
- Why-为什么会发生
- Where-哪个地方发生的问题
- How much-耗费了多少资源，问题解决后能减少多少资源耗用
- How to do-怎么解决问题
但是这些只能给出方向，性能分析需要找到原因需要更具体的方法，怎么解决一个问题也需要更加具体的方式。
Brendan Gregg在《性能之巅：洞悉系统、企业与云计算》第二章中讲到大量的方法，比较突出的如Use方法、负载特征归纳、性能监控、静态性能调优、延时分析、工具法等等。
其中工具法最具体，但是工具法也有自己的限制，如磁盘的饱和度，在磁盘使用率100%的时候，磁盘的负载可能还可以继续增加。在实际分析问题中，负载特征归纳更有指导意义，静态跟踪和动态跟踪让我们更容易更直观发现问题。
CPU
认识CPU
CPU本身的架构和内核调度器的架构这里不做详细讲述，具体可以参考操作系统类书籍。但是仍然需要清楚一些概念：
- 处理器
- 核
- 硬件线程
- CPU内存缓存
- 时钟频率
- 每指令周期数CPI和每周期指令数IPC
- CPU指令
- 使用率
- 用户时间／内核时间
- 调度器
- 运行队列
- 抢占
- 多进程
- 多线程
- 字长
针对应用程序，我们通常关注的是内核CPU调度器功能和性能
线程的状态分析主要是分析线程的时间用在什么地方，而线程状态的分类一般分为：
on-CPU：执行中，执行中的时间通常又分为用户态时间user和系统态时间sys。
off-CPU：等待下一轮上CPU，或者等待I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。
如果大量时间花在CPU上，对CPU的剖析能够迅速解释原因；如果系统时间大量处于off-cpu状态，定位问题就会费时很多。
分析方法与工具
在观察CPU性能的时候，按照负载特征归纳的方法，可以检查如下清单：
- 整个系统范围内的CPU负载如何，CPU使用率如何，单个CPU的使用率呢？
- CPU负载的并发程度如何？是单线程吗？有多少线程？
- 哪个应用程序在使用CPU，使用了多少？
- 哪个内核线程在使用CPU，使用了多少？
- 中断的CPU用量有多少？
- 用户空间和内核空间使用CPU的调用路径是什么样的？
- 遇到了什么类型的停滞周期？
要回答上面的问题，使用系统性能分析工具最经济和直接，这里列举的工具足够回答上面的问题：
| 工具 | 描述 |
| uptime | 平均负载 |
| vmstat | 包括系统范围的CPU平均负载 |
| top | 监控每个进程/线程CPU用量 |
| pidstat | 每个进程／线程CPU用量分解 |
| ps | 进程状态 |
| perf | CPU剖析和跟踪，性能计数器分析 |
上述问题中，调用路径和停滞周期的分析可以使用perf工具，也可以使用DTrace等更灵活的工具。
其中perf支持对各类内核时间的跟踪计数统计，可以使用perf list查看。例如停滞周期分析可能十分复杂，需要对CPU和调度器架构有较系统的认识和了解。
停滞的周期可能发生在一级、二级或者三级缓存，如缓存未命中，也可能是内存IO和资源IO上的停滞周期，perf中有诸如L1-dcahce-loads，L1-icache-loads等事件的计数统计。
Linux查看CPU
cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c
8 Intel(R) Xeon(R) CPU E5410 @ 2.33GHz
(看到有8个逻辑CPU, 也知道了CPU型号)
cat /proc/cpuinfo | grep physical | uniq -c
4 physical id : 0
4 physical id : 1
(说明实际上是两颗4核的CPU)
getconf LONG_BIT
32
(说明当前CPU运行在32bit模式下, 但不代表CPU不支持64bit)
cat /proc/cpuinfo | grep flags | grep ' lm ' | wc -l
8
(结果大于0, 说明支持64bit计算. lm指long mode, 支持lm则是64bit)
再完整看cpu详细信息, 不过大部分我们都不关心而已.
dmidecode | grep 'Processor Information'
查看内存信息
cat /proc/meminfo
uname -a
[Linux] euis1 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux
(查看当前操作系统内核信息)
cat /etc/issue | grep Linux
Red Hat Enterprise Linux AS release 4 (Nahant Update 5)
(查看当前操作系统发行版信息)
查看机器型号
dmidecode | grep "Product Name"
内存
认识内存
如前所述，内存是为提高效率而生，实际分析问题的时候，内存出现问题可能不只是影响性能，而是影响服务或者引起其他问题。同样对于内存有些概念需要清楚：
- 主存
- 虚拟内存
- 常驻内存
- 地址空间
- OOM
- 页缓存
- 缺页
- 换页
- 交换空间
- 交换
- 用户分配器libc、glibc、libmalloc和mtmalloc
- LINUX内核级SLUB分配器
分析方法与工具
Brendan在书中给出了一些问题，比如内存总线的平衡性，NUMA系统中，内存是否被分配到合适的节点中去等等，这些问题在实际分析问题的时候，并不能作为切入点，需要持续的分析。因此笔者简化为如下清单：
- 系统范围内的物理内存和虚拟内存使用率
- 换页、交换、oom的情况
- 内核和文件系统缓存的使用情况
- 进程的内存用于何处
- 进程为何分配内存
- 内核为何分配内存
- 哪些进程在持续地交换
- 进程或者内存是否存在内存泄漏？
内存的分析工具如下：
| 工具 | 描述 |
| free | 缓存容量统计信息 |
| vmstat | 虚拟内存统计信息 |
| top | 监视每个进程的内存使用情况 |
| ps | 进程状态 |
| Dtrace | 分配跟踪 |
除了DTrace，所有的工具只能回答信息统计，进程的内存使用情况等等，至于是否发生内存泄漏等，只能通过分配跟踪。
但是DTrace需要对内核函数有很深入的了解，通过D语言编写脚本完成跟踪。Perf也有一些诸如cache-miss、page-faults的事件用于跟踪，但是并不直观。
Linux查看内存
1. /proc/meminfo
查看RAM使用情况最简单的方法是通过/proc/meminfo。这个动态更新的虚拟文件实际上是许多其他内存相关工具(如：free / ps / top)等的组合显示。/proc/meminfo列出了所有你想了解的内存的使用情况。进程的内存使用信息也可以通过/proc/
$ cat /proc/meminfo
atop命令是一个终端环境的监控命令。它显示的是各种系统资源（CPU, memory, network, I/O, kernel）的综合，并且在高负载的情况下进行了彩色标注。
- atop
$ sudo atop
- free
free命令是一个快速查看内存使用情况的方法，它是对 /proc/meminfo 收集到的信息的一个概述。
$ free -h
4. GNOME System Monitor
GNOME System Monitor 是一个显示最近一段时间内的CPU、内存、交换区及网络的使用情况的视图工具。它还提供了一种查看CPU及内存使用情况的方法。
$ gnome-system-monitor
5. htop
htop命令显示了每个进程的内存实时使用率。它提供了所有进程的常驻内存大小、程序总内存大小、共享库大小等的报告。列表可以水平及垂直滚动。
$ htop
6. KDE System Monitor
- KDE System Monitor
功能同 4 中介绍的GENOME版本。
$ ksysguard
7. memstat
memstat是一个有效识别executable(s), process(es) and shared libraries使用虚拟内存情况的命令。给定一个进程ID，memstat可以列出这个进程相关的可执行文件、数据和共享库。
$ memstat -p
8. nmon
nmon是一个基于ncurses的系统基准测试工具，它可以监控CPU、内存、I/O、文件系统及网络资源等的互动模式。对于内存的使用，它可以实时的显示 总/剩余内存、交换空间等信息。
$ nmon
9. ps
ps命令可以实时的显示各个进程的内存使用情况。Reported memory usage information includes %MEM (percent of physical memory used), VSZ (total amount of virtual memory used), and RSS (total amount of physical memory used)。你可以使用 “–sort”选项对进程进行排序，例如按RSS进行排序：
$ ps aux --sort -rss
10. smem
smem命令允许你统计基于/proc信息的不同进程和用户的内存使用情况。内存使用情况的分析可以导出图表（如条形图和饼图）。
$ sudo smem --pie name -c "pss"
11. top
top命令提供了实时的运行中的程序的资源使用统计。你可以根据内存的使用和大小来进行排序。
$ top
12. vmstat
vmstat命令显示实时的和平均的统计，覆盖CPU、内存、I/O等内容。例如内存情况，不仅显示物理内存，也统计虚拟内存。
$ vmstat -s
实际案例
关于内存泄漏，从监控和顶层观察很难发现问题，一般都是从底层程序代码来分析，案例中使用各种观察工具和跟踪工具都不能很确定原因所在，只能通过分析代码来排查问题。
最终发现是lua脚本语言分配内存速度快，包驱动的周期性服务的用法中，lua自动回收不能迅速释放内存，而是集中回收，如果频繁回收又可能带来CPU的压力。开发项目组最后采用的解决方式为分步回收，每次回收一部分内存，然后周期性全量回收。
IO
逻辑IO vs 物理IO
通常在讨论问题时，总是会分析IO的负载，IO的负载通常指的是磁盘IO，也就是物理IO，例如我们使用iostat获取的avgqu-sz、svctm和until等指标。
因为我们的读写最终都是来自或者去往磁盘的，关注磁盘的IO情况非常正确。但是我们在进行读写操作的时候，面向的对象大多数时候并不会直接面向磁盘，而是面向文件系统的，除非使用raw io的方式。
如下图为通用的IO结构图，如果你想了解更详细，可以查看第二张图片。我们知道LINUX通过文件系统将所有的硬件设备甚至网络都抽象为文件来管理， 例如read()调用时，实际就是就是调用了vfs_read函数，文件系统会确认请求的数据是否在页缓存中，如果不在内存中，于是将请求发送到块设备；
此时内核会先获取到数据在物理设备上的实际位置，然后将读请求发送给块设备的请求队列中，IO调度器会通过一定的调度算法，将请求发送给磁盘设备驱动层，执行真正的读操作。
在这一过程中可能发生哪些情况呢？如果应用程序执行的是大量的顺序读会怎样？随机读又会怎样？如果是顺序读，正确的做法就是进行预读，让请求的数据落到内存中，提升读效率。所以在应用程序发起一次读，从文件系统到磁盘的过程中，存在读放大的问题。
在写操作时同样存在类似的情况，应用程序发起对文件系统的IO操作，物理IO与应用程序之间，有时候会显得无关、间接、放大或者缩小。
无关：
- 其他的应用程序：磁盘IO来自其他的应用程序，如监控，agent等
- 其他用户：如同虚拟机母机下的其他用户
- 其他内核任务：如重建raid，校验等
间接： - 文件系统预读：增加额外的IO，但是可能预读的数据无用
- 文件系统缓冲：写缓存推迟或者合并回写磁盘，造成磁盘瞬时IO压力
放大： - 文件系统元数据：增大额外的IO
- 文件系统记录尺寸：向上对齐等增加了IO大小
缩小： - 文件系统缓存：直接读取缓存，而不需要操作磁盘
- 合并：一次性回写磁盘
- 文件系统抵消：同一地址更新多次，回写磁盘时只保留最后一次修改
- 压缩：减少数据量
文件系统分析与工具
与文件系统相关的术语如下：
- 文件系统
- VFS
- 文件系统缓存
- 页缓存page cache
- 缓冲区高速缓存buffer cache
- 目录缓存
- inode
- inode缓存
如下图为文件系统缓存的结构图，页缓存缓存了虚拟内存的页面，包括文件系统的页面，提升了文件和目录的性能。Linux将缓冲区高速缓存放入到了页缓存中，即page cache包含buffer cache。
文件系统使用的内存脏页由内核线程写回磁盘，如图中的页面扫描器kswapd为后台的页面换出进程，当内存不足，超过一定时间（30s）或者有过多的脏页时都会触发磁盘回写。
文件系统延时指的是一个文件系统逻辑请求从开始到结束的时间，包括在文件系统、内核磁盘IO子系统以及等待磁盘设备响应的时间。同步访问时，应用程序会在请求时阻塞，等待文件系统请求结束，异步方式下，文件系统对其并无直接影响。
但是异步访问也分select、poll、epoll等方式，也就是所谓的异步阻塞、异步非阻塞。在异步方式下，一般是打印出用户层发起文件系统逻辑IO的调用栈，得到调用了哪个函数产生了IO。
Linux未提供查看文件系统延时的工具和接口，但是磁盘的指标信息却比较丰富，但是很多情况下，文件系统IO和磁盘IO之间并没有直接关系，例如应用程序写文件系统。
但是根本不关心数据什么时候写到磁盘了，而后台刷数据到磁盘时，可能造成磁盘IO负载增加，从磁盘角度，应用程序的写入可能受到影响了，而实际上应用程序并没有等待。
文件系统的分析可以试着回答下面的问题： - 哪个应用程序在使用文件系统？
- 在对哪些文件进行操作？
- 在进行什么样的操作，读写比是多少，同步还是异步？
- 文件系统的缓存有多大，目前的使用情况？
- 有遇到什么错误吗？是请求不合法，还是文件系统自身的问题？
其实上面的问题，除了能够看到系统的内存情况，页缓存和buffer cache大小，能够看到哪些进程在进行读写操作，在读哪些文件，其他的比如应用程序对文件系统的读写比，同步还是异步，这些问题没有工具能给出明确的信息。当然我们可以通过跟踪应用程序的内核调用栈来发现问题，也可以在应用程序中输出日志来帮助分析。
磁盘分析与工具
在理解磁盘IO之前，同样我们需要理解一些概念，例如：
- 虚拟磁盘
- 扇区
- I/O请求
- 磁盘命令
- 带宽
- 吞吐
- I/O延时
- 服务时间
- 等待时间
- 随机IO/连续IO
- 同步/异步
- 磁盘接口
- Raid
对于磁盘IO，我们可以列出如下等问题来帮助我们分析性能问题： - 每块磁盘的使用率是多少？
- 每块磁盘上有多长等待队列？
- 平均服务时间和等待时间时多少？
- 是哪个应用程序或者用户正在使用磁盘？
- 应用程序读写的方式是怎样的？
- 为什么会发起磁盘IO，内核调用路径是什么样的？
- 磁盘上的读写比是多少？
- 随机IO还是顺序IO？
Linux对磁盘的性能分析工具主要如下：
| 工具 | 描述 |
| iostat | 各种单个磁盘统计信息 |
| iotop、pidstat | 按进程列出磁盘IO的使用情况 |
| perf、Dtrace | 跟踪工具 |
磁盘上是随机IO还是顺序IO，很多时候我们并没有很好的方式去判断，因为块设备回写磁盘的时候，随机IO可能已经被整理为顺序IO了。对于磁盘的分析同样可以使用perf跟踪事件或者DTrace设置探针。
在分析mysql在某机型上做非全cache非原地更新时，为什么单实例无法将机器性能压满的时候，我们在分析的过程中跟踪了块设备的内核事件。我们对比了多实例非原地更新和单实例非原地更新的时候，磁盘的操作情况。如下为非原地更新时跟踪的结果。
对结果分析后看到，单实例非原地更新时，将近30%是blk_finish_plug，有70%是blk_queue_bio，而多实例时正好相反，大量的blk_finish_plug和少量的blk_queue_bio（当然，这不是为什么性能压不满的原因）。
Linux查看IO
1 系统级IO监控
iostat
iostat -xdm 1 # 个人习惯
%util 代表磁盘繁忙程度。100% 表示磁盘繁忙, 0%表示磁盘空闲。但是注意,磁盘繁忙不代表磁盘(带宽)利用率高
argrq-sz 提交给驱动层的IO请求大小,一般不小于4K,不大于max(readahead_kb, max_sectors_kb)
可用于判断当前的IO模式,一般情况下,尤其是磁盘繁忙时, 越大代表顺序,越小代表随机
svctm 一次IO请求的服务时间,对于单块盘,完全随机读时,基本在7ms左右,既寻道+旋转延迟时间
注: 各统计量之间关系
=======================================
%util = ( r/s + w/s) * svctm / 1000 # 队列长度 = 到达率 * 平均服务时间
avgrq-sz = ( rMB/s + wMB/s) * 2048 / (r/s + w/s) # 2048 为 1M / 512
=======================================
总结:
iostat 统计的是通用块层经过合并(rrqm/s, wrqm/s)后,直接向设备提交的IO数据,可以反映系统整体的IO状况,但是有以下2个缺点:
1 距离业务层比较遥远,跟代码中的write,read不对应(由于系统预读 + pagecache + IO调度算法等因素, 也很难对应)
2 是系统级,没办法精确到进程,比如只能告诉你现在磁盘很忙,但是没办法告诉你是谁在忙,在忙什么？
2 进程级IO监控
iotop 和 pidstat (仅rhel6u系列)
iotop 顾名思义, io版的top
pidstat 顾名思义, 统计进程(pid)的stat,进程的stat自然包括进程的IO状况
这两个命令,都可以按进程统计IO状况,因此可以回答你以下二个问题
- 当前系统哪些进程在占用IO,百分比是多少?
- 占用IO的进程是在读?还是在写?读写量是多少?
pidstat 参数很多,仅给出几个个人习惯
pidstat -d 1 #只显示IO
pidstat -u -r -d -t 1 # -d IO 信息,
# -r 缺页及内存信息
# -u CPU使用率
# -t 以线程为统计单位
# 1 1秒统计一次
iotop, 很简单,直接敲命令
block_dump, iodump
iotop 和 pidstat 用着很爽,但两者都依赖于/proc/pid/io文件导出的统计信息, 这个对于老一些的内核是没有的,比如rhel5u2
因此只好用以上2个穷人版命令来替代:
echo 1 > /proc/sys/vm/block_dump # 开启block_dump,此时会把io信息输入到dmesg中
# 源码: submit_bio@ll_rw_blk.c:3213
watch -n 1 "dmesg -c | grep -oP \"\w+\(\d+\): (WRITE|READ)\" | sort | uniq -c"
# 不停的dmesg -c
echo 0 > /proc/sys/vm/block_dump # 不用时关闭
也可以使用现成的脚本 iodump, 具体参见 http://code.google.com/p/maatkit/source/browse/trunk/util/iodump?r=5389
iotop.stp
systemtap脚本,一看就知道是iotop命令的穷人复制版,需要安装Systemtap, 默认每隔5秒输出一次信息
stap iotop.stp # examples/io/iotop.stp
总结
进程级IO监控 ，
- 可以回答系统级IO监控不能回答的2个问题
- 距离业务层相对较近(例如,可以统计进程的读写量)
但是也没有办法跟业务层的read,write联系在一起,同时颗粒度较粗,没有办法告诉你,当前进程读写了哪些文件? 耗时? 大小 ？
3 业务级IO监控
ioprofile
ioprofile 命令本质上是 lsof + strace, 具体下载可见 [http://code.google.com/p/maatkit/](http://code.google.com/p/maatkit/)
ioprofile 可以回答你以下三个问题:
1 当前进程某时间内,在业务层面读写了哪些文件(read, write)？
2 读写次数是多少?(read, write的调用次数)
3 读写数据量多少?(read, write的byte数)
假设某个行为会触发程序一次IO动作,例如: "一个页面点击,导致后台读取A,B,C文件"
============================================
./io_event # 假设模拟一次IO行为,读取A文件一次, B文件500次, C文件500次
ioprofile -ppidof io_event-c count # 读写次数
ioprofile -ppidof io_event-c times # 读写耗时
ioprofile -ppidof io_event-c sizes # 读写大小
注: ioprofile 仅支持多线程程序,对单线程程序不支持. 对于单线程程序的IO业务级分析,strace足以。
总结:
ioprofile本质上是strace,因此可以看到read,write的调用轨迹,可以做业务层的io分析(mmap方式无能为力)
4 文件级IO监控
文件级IO监控可以配合/补充"业务级和进程级"IO分析
文件级IO分析,主要针对单个文件, 回答当前哪些进程正在对某个文件进行读写操作.
1 lsof 或者 ls /proc/pid/fd
2 inodewatch.stp
lsof 告诉你 当前文件由哪些进程打开
lsof ../io # io目录 当前由 bash 和 lsof 两个进程打开
lsof 命令 只能回答静态的信息, 并且"打开" 并不一定"读取", 对于 cat ,echo这样的命令, 打开和读取都是瞬间的,lsof很难捕捉
可以用 inodewatch.stp 来弥补
stap inodewatch.stp major minor inode # 主设备号, 辅设备号, 文件inode节点号
stap inodewatch.stp 0xfd 0x00 523170 # 主设备号, 辅设备号, inode号,可以通过 stat 命令获得
5 磁盘碎片整理
一句话: 只要磁盘容量不常年保持80%以上,基本上不用担心碎片问题。
如果实在担心,可以用 defrag 脚本
6 其他IO相关命令
blockdev 系列
blockdev --getbsz /dev/sdc1 # 查看sdc1盘的块大小
block blockdev --getra /dev/sdc1 # 查看sdc1盘的预读(readahead_kb)大小
blockdev --setra 256 /dev/sdc1 # 设置sdc1盘的预读(readahead_kb)大小,低版的内核通过/sys设置,有时会失败,不如blockdev靠谱
Linux查看磁盘
df -h：查看磁盘占用情况
df -T：查看所有磁盘的文件系统类型(type)
fdisk -l：查看所有被系统识别的磁盘
mount -t type device dir：挂载device到dir
Linux查看GPU
1. 显示当前GPU使用情况
Nvidia自带了一个nvidia-smi的命令行工具，会显示显存使用情况：
$ nvidia-smi
输出：
2. 周期性输出GPU使用情况
但是有时我们希望不仅知道那一固定时刻的GPU使用情况，我们希望一直掌握其动向，此时我们就希望周期性地输出，比如每 10s 就更新显示。 这时候就需要用到 watch命令，来周期性地执行nvidia-smi命令了。
了解一下watch的功能：
$ whatis watch
watch(1) - execute a program periodically, showing output fillscreen
作用：周期性执行某一命令，并将输出显示。
watch的基本用法是：
$ watch [options] command
最常用的参数是 -n， 后面指定是每多少秒来执行一次命令。
监视显存：我们设置为每 10s 显示一次显存的情况：
$ watch -n 10 nvidia-smi
显示如下：
这样，只要开着这个命令行窗口，就可以每十秒刷新一次，是不是很方便呢？
如果我们希望来周期性地执行其他命令行操作，那么就可以简单地更换后面的nvidia-smi即可，So Cool !
具体如下所示：重要的参数主要是温度、内存使用、GPU占有率，具体如下红框所示。
Linux查看网络
ifconfig
netstat