top命令用法
 
top命令经常用来监控linux的系统状况，是常用的性能分析工具，能够实时显示系统中各个进程的资源占用情况。
 
top的使用方式 top [-d number] | top [-bnp]
 
参数解释：
 
-d：number代表秒数，表示top命令显示的页面更新一次的间隔。默认是5秒。 -b：以批次的方式执行top。 -n：与-b配合使用，表示需要进行几次top命令的输出结果。 -p：指定特定的pid进程号进行观察。
 
在top命令显示的页面还可以输入以下按键执行相应的功能（注意大小写区分的）：
 
?：显示在top当中可以输入的命令 P：以CPU的使用资源排序显示 M：以内存的使用资源排序显示 N：以pid排序显示 T：由进程使用的时间累计排序显示 k：给某一个pid一个信号。可以用来杀死进程 r：给某个pid重新定制一个nice值（即优先级） q：退出top（用ctrl+c也可以退出top）。
 
top各输出参数含义
 
下面是使用top命令来进行性能检测的截图：
 
图一(ubuntu)：
 
 
图二(centos)：
 
 
一、top前5行统计信息
 
第1行：top - 05:43:27 up 4:52, 2 users, load average: 0.58, 0.41, 0.30 
 第1行是任务队列信息，其参数如下：
 
内容
含义
05:43:27
表示当前时间
up 4:52
系统运行时间 格式为时：分
2 users
当前登录用户数
load average: 0.58, 0.41, 0.30
系统负载，即任务队列的平均长度。 三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值。
load average: 如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了。 

第2行：Tasks: 159 total, 1 running, 158 sleeping, 0 stopped, 0 zombie 
第3行：%Cpu(s): 37.0 us, 3.7 sy, 0.0 ni, 59.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st 
 第2、3行为进程和CPU的信息 
 当有多个CPU时，这些内容可能会超过两行，其参数如下：
 
内容
含义
159 total
进程总数
1 running
正在运行的进程数
158 sleeping
睡眠的进程数
0 stopped
停止的进程数
0 zombie
僵尸进程数
37.0 us
用户空间占用CPU百分比
3.7 sy
内核空间占用CPU百分比
0.0 ni
用户进程空间内改变过优先级的进程占用CPU百分比
59.3 id
空闲CPU百分比
0.0 wa
等待输入输出的CPU时间百分比
0.0 hi
硬中断（Hardware IRQ）占用CPU的百分比
0.0 si
软中断（Software Interrupts）占用CPU的百分比
0.0 st
 

 第4行：KiB Mem: 1530752 total, 1481968 used, 48784 free, 70988 buffers 
 第5行：KiB Swap: 3905532 total, 267544 used, 3637988 free. 617312 cached Mem 
 第4、5行为内存信息 
 其参数如下：
 
内容
含义
KiB Mem: 1530752 total
物理内存总量
1481968 used
使用的物理内存总量
48784 free
空闲内存总量
70988 buffers（buff/cache）
用作内核缓存的内存量
KiB Swap: 3905532 total
交换区总量
267544 used
使用的交换区总量
3637988 free
空闲交换区总量
617312 cached Mem
缓冲的交换区总量。
3156100 avail Mem
代表可用于进程下一次分配的物理内存数量
上述最后提到的缓冲的交换区总量，这里解释一下，所谓缓冲的交换区总量，即内存中的内容被换出到交换区，而后又被换入到内存，但使用过的交换区尚未被覆盖，该数值即为这些内容已存在于内存中的交换区的大小。相应的内存再次被换出时可不必再对交换区写入。 

 计算可用内存数有一个近似的公式： 
 第四行的free + 第四行的buffers + 第五行的cached
 
二、进程信息
 
列名
含义
PID
进程id
PPID
父进程id
RUSER
Real user name
UID
进程所有者的用户id
USER
进程所有者的用户名
GROUP
进程所有者的组名
TTY
启动进程的终端名。不是从终端启动的进程则显示为 ?
PR
优先级
NI
nice值。负值表示高优先级，正值表示低优先级
P
最后使用的CPU，仅在多CPU环境下有意义
%CPU
上次更新到现在的CPU时间占用百分比
TIME
进程使用的CPU时间总计，单位秒
TIME+
进程使用的CPU时间总计，单位1/100秒
%MEM
进程使用的物理内存百分比
VIRT
进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
SWAP
进程使用的虚拟内存中，被换出的大小，单位kb
RES
进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
CODE
可执行代码占用的物理内存大小，单位kb
DATA
可执行代码以外的部分(数据段+栈)占用的物理内存大小，单位kb
SHR
共享内存大小，单位kb
nFLT
页面错误次数
nDRT
最后一次写入到现在，被修改过的页面数。
S
进程状态。D=不可中断的睡眠状态 R=运行 S=睡眠 T=跟踪/停止 Z=僵尸进程
COMMAND
命令名/命令行
WCHAN
若该进程在睡眠，则显示睡眠中的系统函数名
Flags
任务标志
其他
 
默认进入top时，各进程是按照CPU的占用量来排序的。
 
1、在top基本视图中，按键盘数字“1”可以监控每个逻辑CPU的状况： 
 
 
 2、敲击键盘‘b’（打开关闭加亮效果）top视图变换如下： 
 
 
PID为16283为当前top视图中唯一的运行态进程。也可以敲击键盘‘y’来打开或者关闭运行态进程的加亮效果。
 
3、敲击键盘‘x’（打开/关闭排序列的加亮效果），top视图变换如下： 
 
 
可以看到现在是按"%CPU"进行排序的，可以按”shift+>”或者”shift+<”左右改变排序序列。
 
4、改变进程显示字段
 
在top基本视图中，敲击”f”进入另一个视图，在这里可以编辑基本视图中的显示字段：
 
 
 
用上下键选择选项，按下空格键可以决定是否在基本视图中显示这个选项。
 
top命令是一个非常强大的功能，但是它监控的最小单位是进程，如果想监控更小单位时，就需要用到ps或者netstate命令来满足我们的要求。
 
参考文献
 
1、https://blog.csdn.net/quiet_girl/article/details/50668126
 
2、http://www.zhimengzhe.com/linux/298422.html

转自：https://fangpeishi.com/tops.html
 
Linux *top
 
 
  
apachetop
atop
biotop
cachetop
ctop
dnstop
filetop
gtop
hatop
htop
iftop
iotop
itop
jnettop
kerneltop
latencytop
logtop
lttngtop
mtop
mytop
ntop
numatop
pgtop
powertop
ptop
qtop
radeontop
slabratetop
slabtop
sntop
systemd-cgtop
tcptop
tiptop
top
treetop
virt-top
wmtop
xrestop
Glances

 图片来源：http://www.brendangregg.com/linuxperf.html
 
Linux 下有很多 *top 工具，收集一番? 。
 apachetop atop biotop cachetop ctop dnstop filetop gtop hatop htop iftop iotop itop jnettop kerneltop latencytop logtop lttngtop mtop mytop ntop numatop pgtop powertop ptop qtop radeontop 。。。
 
apachetop
 
图片来源：Monitor Your Website in Real-Time with Apachetop
 
 
 
ApacheTop watches a logfile generated by Apache (in standard common or combined logformat, and generates human-parsable output in realtime.
 
 
项目地址：github.com/tessus/apachetop
 
读取Apache 的日志，实时分析，生成统计数据。Nginx 也有一个GoAccess，更加酷炫： 
 
atop
 
 
项目地址：www.atoptool.nl
 
和top 很像，不过强大一些，有不同的视图，内存、命令、磁盘、网络等，具体可以看截图。
 为了分析进程的网络使用情况，atop 带了一个内核模块netatop:
 
 
 
The optional kernel module netatop can be loaded to gather statistics about the TCP and UDP packets that have been transmitted/received per process and per thread.
 
 
 
biotop
 
 
 
 
biotop - Block device (disk) I/O by process top.
 
 
biotop 是iovisor/bcc 项目里一段Python 脚本，代码见：bcc/tools/biotop.py，
 使用说明：bcc/tools/biotop_example.txt，biotop-bpfcc.8。
 
cachetop
 
 
 
 
show Linux page cache hit/miss statistics including read and write hit % per
 
 
展示Linux page cache 的命中情况，脚本地址：bcc/tools/cachetop.py，使用说明：bcc/tools/cachetop_example.txt
 
ctop
 
 
 
 
Top-like interface for container metrics
 
 
ctop 用来在宿主机上统计、获取docker container CPU/内存/网络等指标，比较新的项目，非常酷炫。
 项目地址：ctop.sh
 
dnstop
 
 
 
 
dnstop - displays various tables of DNS traffic on your network
 
 
监听网卡，抓包，统计分析DNS 相关的流量，可以用来分析本机出去的DNS 查询请求，也可以在DNS 服务器上分析入的查询请求。 项目地址：dnstop
 
filetop
 
 
 
 
filetop shows reads and writes by file, with process details.
 
 
展示进程对每个文件（包括普通文件，socket，管道等）的读写次数、读写量。filetop 和 cachetop、biotop一样，都是iovisor/bcc 这个项目中的脚本。
 
脚本地址：bcc/tools/filetop.py，使用说明：bcc/tools/filetop_example.txt。
 
gtop
 
 
 
 
System monitoring dashboard for terminal.
 
 
一个用Node.JS 写的系统仪表盘，没什么特殊，项目地址：aksakalli/gtop
 
hatop
 
 
 
 
HATop is an interactive ncurses client and real-time monitoring, statistics displaying tool for the HAProxy TCP/HTTP load balancer.
 
 
可以用于HAProxy 的分析工具，应该是基于HAProxy 提供的socket api 开发的，除了流量、状态统计，还可以开关server 节点、更改权重等，项目地址：feurix.org/projects/hatop/。
 
htop
 
 
 
 
This is htop, an interactive process viewer for Unix systems. It is a text-mode application (for console or X terminals) and requires ncurses.
 
 
非常厉害，非常强大，非常酷炫的top 替代品，居家旅行必备，值得拥有，项目地址：hisham.hm/htop/。
 
iftop
 
 
 
 
iftop - display bandwidth usage on an interface by host
 
 
iftop 是一个实时监控网络流量的工具，可以非常方便的看到连接的来源与目的、端口、接收/发送速度等信息，项目地址：www.ex-parrot.com/~pdw/iftop/。
 
iotop
 
 
 
 
iotop is a Python program with a top like UI used to show of behalf of which process is the I/O going on
 
 
用iotop 可以看到每个进程具体的IO，类似top 的页面，能很方便的找出是哪些进程在占用磁盘IO，项目地址:guichaz.free.fr/iotop/。
 
itop
 

 图片来源：itop – Interrupts ‘top-like’ utility for Linux
 
itop 是一个perl 脚本，统计各个中断源的中断次数，项目地址：kargig/itop。
 
itop更方便的了解Linux下中断情况
jnettop
 
 
 
 
jnettop - View hosts/ports taking up the most network traffic
 
 
参考：nethogs 以及 jnettop 的使用
 
 
 
nethogs 可以用来监控进程消耗的带宽，而 jnettop 则使用来记录每个 IP 的带宽的使用情况。
 
 
用户手册：jnettop(8) ，项目地址已经无法打开。
 
kerneltop
 
图片来源：asciinema.org
 
 
 
shows kernel function usage in an interactive style like 'top'
 
 
统计展示内核函数调用次数，使用手册：kerneltop.1。
 
latencytop
 
 
 
 
LatencyTOP is a Linux* tool for software developers (both kernel and userspace), aimed at identifying where in the system latency is happening, and what kind of operation/action is causing the latency to happen so that the code can be changed to avoid the worst latency hiccups.
 
 
具体介绍看这篇文章就好了：latencytop深度了解你的Linux系统的延迟，项目地址：www.latencytop.org，已经打不开了。
 
logtop
 
 
 
 
Display real time statistics of whatever you want.
 
 
可以用来代替uniq -c|sort 的小工具，给它喂一段数据，自动统计排序，项目地址：julienpalard.github.io/logtop/。
 
lttngtop
 

 图片来源：LTTngTop view of I/O activity
 
 
 
Lttngtop is an Ncurses interface for reading and browsing traces recorded by the LTTng tracer and displaying various statistics.
 
 
lttngtop 可以把LTTng 的分析结果以top 的方式展示，使用手册：lttngtop.1.。
 
mtop
 
 
 
 
mtop (MySQL top) monitors a MySQL server showing the queries which are taking the most amount of time to complete.
 
 
一个用于MySQL 的工具，以top 的方式展示当前的查询语句与耗时，项目地址：mtop.sourceforge.net。
 
mytop
 
 
 
 
a top clone for MySQL
 
 
也是一个用于MySQL 的工具，直观的展示当前数据库的状态，项目地址：http://jeremy.zawodny.com/mysql/mytop/。
 
ntop
 
 
 
 
High-Speed Web-based Traffic Analysis and Flow Collection
 
 
ntop一个网络流量监控分析工具，提供了web 页面，非常美观，项目地址：ntop.org。
 
numatop
 

 图片来源：NumaTop: A NUMA system monitoring tool
 
 
 
NumaTOP is an observation tool for runtime memory locality characterization and analysis of processes and threads running on a NUMA system.
 
 
NUMA 的机器，内存是按照处理器进行分配的，有本地内存（LMA）与非本地内存（RMA）的区别，numatop 可以统计进程对RMA和LMA 的使用情况，项目地址：intel/numatop。
 
numatop introduction
pgtop
 
 
 
 
pgtop, display PostgreSQL processes in `top' style
 
 
类似mytop，pgtop 是一个用于PostgreSQL 的监控工具，项目地址/使用手册：search.cpan.org/dist/pgtop/pgtop。
 
powertop
 
 
 
 
a tool that helps you find what software is using the most power
 
 
archlinux_wiki_powertop：
 
 
 
PowerTOP 是一个Intel提供的在用户空间、内核和硬件层面的节电工具。它可以监视进程，并显示哪些进程利用CPU并从空闲状态唤醒它，从而识别具有特殊高功率需求的应用程序。
 
 
项目地址：www.allkentuckyhotels.com/linuxpowertoporg/.
 
ptop
 
 
用Python 写的类似top 的工具，项目地址：darxtrix.in/ptop/。
 
qtop
 
 
 
 
qtop (pronounced queue-top) is a tool written in order to summarize the state of an LRMS (Local Resource Management System)
 
 
项目地址：fotis.web.cern.ch/fotis/QTOP/。
 
radeontop
 
 
 
 
View your GPU utilization, both for the total activity percent and individual blocks.
 
 
查看GPU 的使用情况，项目地址：clbr/radeontop
 
slabratetop
 
 
 
 
slabratetop shows the rate of allocations and total bytes from the kernel memory allocation caches (SLAB or SLUB), in a top-like display that refreshes.
 
 
slabratetop 统计展示SLAB 和SLUB 分配器分配内存的情况，项目地址：bcc/tools/slabratetop.py，使用手册：bcc/tools/slabratetop_example.txt。
 
Linux SLUB 分配器详解
Linux slab 分配器剖析
slabtop
 
 图片来源：slabtop简单的用途
 
 
 
display kernel slab cache information in real time
 
 
slaptop 是procps 里的一个工具，用来查看系统slab 的分布情况。
 
sntop
 
 
 
 
simple network top
 
 
一个简单的工具，可以配置一些地址，使用fping 探测地址的可用性，然后统计展示，项目地址：sntop.sourceforge.net。
 
systemd-cgtop
 
 
 
 
Show top control groups by their resource usage
 
 
systemd-cgtop 是systemd 带的一个工具，展示systemd 下各个单元文件（slice,service,scopt 等）的资源使用情况，操作说明：systemd-cgtop。
 
tcptop
 
 
 
 
display top TCP network packets by process
 
 
统计展示本地tcp 连接情况，项目地址：linux-bcc-tcptop。
 
tiptop
 
 
 
 
Tiptop reads hardware performance counters and displays statistics about running processes, such as IPC, or cache misses. The statistics are shown in real time, in a way very similar to the "top" utility.
 
 
tiptop 读取CPU 硬件数据（IPC，cache missess等），可以看到每个进程的情况，项目地址：tiptop.gforge.inria.fr。
 
top
 
 
 
 
display Linux tasks
 
 
top 就是top 啦，无需介绍，使用手册：man top。
 
treetop
 
 
 
 
accurate memory and CPU usage stats for a linux process tree.
 
 
treetop ，可以很方便的统计出进程，以及它的子进程的资源占用情况，项目地址：turbo/treetop。
 
virt-top
 
 
 
 
'top'-like utility for virtualization stats
 
 
项目地址：people.redhat.com/rjones/virt-top/。
 
wmtop
 
 
 
 
wmtop is a windowmaker dock app to display the top 3 processes running on a unix box displaying the cpu usage or memory usage in an attractive graphical way using little screen real estate. It's a kind of mini 'top'.
 
 
桌面环境的小工具，看起来相当古老，项目地址：wmtop.sourceforge.net。
 
xrestop
 
 
 
 
Xrestop uses the X-Resource extension to provide 'top' like statistics of each connected X11 client's server side resource usage
 
 
统计桌面环境组件资源消耗的top工具，项目地址：xrestop。
 
Glances
 
 
 
 
Glances an Eye on your system. A top/htop alternative.
 
 
类top 工具，强大、酷炫值得拥有，不过个人觉得对于运维来说好像不太实用，项目地址：nicolargo/glances。

本手册译自: https://www.ibm.com/developerworks/data/library/techarticle/dm-0812wang/
 
 
 
目录
 
 
 
1.db2top命令语法... 4
 
2.db2top运行模式... 5
 
2.1 交互模式... 5
 
2.2 批量模式... 6
 
3.db2top监控模式... 8
 
3.1 数据库监控 (d). 8
 
3.2 表空间监控 (t). 9
 
3.3 动态SQL监控(D). 10
 
3.4 会话监控 (l). 12
 
3.5 缓存池监控(b). 13
 
3.6 锁监控(U). 14
 
3.7 表监控 (T). 17
 
3.8 瓶颈监控 (B). 17
 
4.其他... 20
 
 
 
 
 
 
 
 
 
1.db2top命令语法
 
 
 
 
可使用命令行 db2top –h 查看，这里就不做赘述了。
 
 
 
2.db2top运行模式
 
db2top一般有两种运行模式， 交互模式和批量模式。
 
交互模式下，用户可直接输入命令后，等待系统响应。注意键盘上的方向左键“←”和方向右键“→”，可用来滚动查看对应方向上的隐藏列。而批量模式下，可无需用户交互即可执行一系列操作。
 
 
 
2.1 交互模式
 
执行如下命令:
 
db2top –d sample
 

图1. 将db2top运行在交互模式
 
 
 
 
图1中的屏幕，最上方有状态栏:
 
[\]15:38:20, refresh=2secs(0.003) AIX, part=[1/1],SHENLI:SAMPLE
 
 
 
· [/]: 当该值滚动时，代表db2top正处在2次快照之间，否则，代表db2top正在等待DB2的响应
 
· 15:38:20: 当前时间
 
· refresh=2secs: 刷新时间间隔
 
· refresh=!secs: 如果出现感叹号，代表处理DB2快照用时比刷新时间间隔要长。这种情况下，db2top刷新时间间隔高了50%。如果由于数据库系统繁忙导致感叹号出现的太过频繁，你可以将刷新时间间隔改高（I选项），或者只监控单独的数据库分区（选项P），又或者关掉额外的监控展示模式(选项X)。
 
· 0.003: DB2处理快照的内部耗时。
 
· AIX: DB2运行平台
 
· Inactive: 代表数据库还未启动，否则代表数据库已启动。
 
· part=[1/1]: 启动的数据库分区数量/总数据库分区数量。举个例子, part=[2,3] 代表3个数据库分区中有1个数据库分区未启动(活动2, 总数3).
 
· SHENLI: 实例名
 
· SAMPLE: 数据库名
 
 
 
[d=Y,a=N,e=N,p=ALL] [qp=off]
 
· d=Y/N: 代表增量或累计快照指示(命令行 -k 或 选项 k)
 
· a=Y/N: 代表只显示已启动对象或显示所有对象 (命令行-a 或者选项i)
 
· e=Y/N: 代表是否显示额外项
 
· p=ALL: 所有数据库分区
 
· p=CUR: 当前数据库分区(命令行-P且未指定数据库分区号)
 
· p=3: 目标数据库分区号: 如3
 
· db2top 可用来监控DPF环境。如果命令行未指定-P,则将生成全局快照。
 
· qp=off/on: 查询动态指示 (DYNMGMT 数据库配置参数) db2top所属的数据库分区
 
 
 
状态栏下方有一个用户手册，可按对应按键选择
 
 
 
2.2 批量模式
 
你可使用db2top 的批量模式来静默地监控数据库。用户可在后台记录性能信息和存储历史数据，以供后续分析。
 
 
 
下列代码列出了如何把db2top在批量模式运行一段时间（例如，总计运行8小时，每15秒收集一次快照数据）:
 
 
 
 
db2top -d sample -f collect.file -C -m 480 -i 15
 
 
 
should I create a named pipe instead of a file [N/y]? N
 
注意：请确保输入 N应答系统提出的这个问题
 
 
 
数据收集至文件后，用户可用下列命令运行db2top的回放模式，来分析收集的数据：
 
db2top -d sample -f collect.file -b l -A
 
选项-A 支持自动性能分析。所以上面的命令将会分析大多数的活动会话，也会占用更多的CPU资源。
 
 
 
也可用下列命令运行db2top的回放模式，来分析指定时间的数据：
 
db2top -d sample -f collect.file /HH:MM:SS
 
 
 
例如，如下命令，用户可重启db2top至回放模式，并跳转到上午2点时的数据：
 
db2top -d sample -f collect.file /02:00:00
 
之后，用户可输入I来分析当时会话的行为。
 
 
 
 
 
3.db2top监控模式
 
3.1 数据库监控 (d)
 
 
 
图2.监控数据库
 
 
 
 
数据库监控模式下，db2top为整个数据库提供一套性能要素的监控。用户可以监控活动会话(MaxActSess)，排序内存(SortMemory)，以及日志空间(LogUsed)。这些监控要素可以帮助用户识别这些要素的当前使用率。如果这些要素其中一个的使用率开始升高甚至达到百分之百，用户应当研究相关的原因。
 
 
 
计算当前时间和Start Time差值，可知数据库已经启动了多久。这个数值在配合其他的监控要素，来解决已经持续一段时间的问题时，就会非常有用。锁使用(LockUsed) 和锁升级(LockEscals)对解决锁相关问题很有帮助。如果观察到大量的锁升级，最好改大数据库的两个参数：LOCKLIST 和MAXLOCKS，或者重点关注那些可能需要大量锁的错误语句。
 
 
 
L_Reads， P_Reads，以及A_Reads分别代表逻辑读，物理读，和异步读。结合命中率(HitRatio)，这些变量可重点用来衡量大多数读操作发生在内存I/O还是磁盘I/O。由于磁盘I/O比内存慢很多，用户应尽量通过内存使用数据。当看到命中率降低时，这就是关注缓存池是否不足，或者是否有需要太多表扫描和内存磁盘交换的错误查询的最好时机。
 
 
 
类似读操作，A_Writes代表异步写，这表示在需要缓存池空间之前，数据页是通过异步页清除器代理执行写操作的。知道了db2top的刷新用时期间的写次，用户也可以了解数据库执行了多少写请求。这可以计算每次写操作的瓶颈用时，然后可以用来分析由I/O 瓶颈导致的性能问题。另外，用户可能希望通过计算A_Writes/Writes的最大值来得知的写I/O的最佳性能。
 
 
 
SortOvf代表排序溢出。如果用户发现这个值非常高，这时最好看下查询语句。排序溢出发生在排序堆不足时，所以SORT或者 HashJoin操作可能把数据溢出到临时空间去。有时候这值会因排序堆调大而下降，但在其他的情况下，如果被排序的数据套比存收集到的排序堆的内存大很多，则会不起作用。在那种情况下，排序溢出会成为一个主要瓶颈。如果数据量需要比缓存池临时空间能承受大，就需要物理I/O来处理 SORT或者Hash Join。因此优化查询来减少排序溢出能够显著地提升系统性能。
 
 
 
数据库监控模式的最后四个条目显示的是平均物理读取时间(AvgPRdTime)，平均直接读取时间 (AvgDRdTime)，平均物理写入时间(AvgPWrTime)，以及平均直接写入时间(AvgDWrTime)。这四个条目直接反应了I/O子系统的性能。如果用户在各项读操作和写操作中，观察到不寻常的大量时间消耗，此时用户应当深入分析I/O子系统。
 
 
 
 
 
3.2 表空间监控 (t)
 
 
 
图3.表空间监控
 
 
 
 
表空间监控模式为每一个表空间提供详细的监控信息。列Hit Ratio%和列Async Read%对很多用户来说非常重要。在数据库级别下只监控缓存池命中率，你可能得不到足够精确的信息。在包含许多表空间的环境下，一个发生在单个表空间的错误查询语句会因平均所有表空间的命中率而被掩盖。在表空间层级上监控列Hit Ratio%和Async Read% 可以有效分析系统的工作细节。
 
 
 
增量逻辑读取(写入)和增量物理读取(写入) (Delta l_reads(writes) 和 Delta p_reads(writes))说明了那些表空间有多 "忙碌"。 一些表空间可能没有很高的缓存池命中率，但它们也可能没有太多活动。在大多数情况下，最好将更多的调优工作放在活动更多的表空间，而不是那些空闲的表空间中。
 
 
 
键盘上的方向左键“←”和方向右键“→”可以将列向左或向右滚动。表空间监控模式和一些其他的监控模式可能有多个且不能显示在同一屏的列。通过按方向左键“←”或方向右键“→”，用户可以滚动屏幕以展示更多列。
 
 
 
按方向左键“←”，用户可以看到更多的读/写条目。另外，平均读/写时间(vg RdTime/Avg WrTime)可被用于理解表空间中每次读/写平均耗时。
 
 
 
列Space Used，列Total Size，以及列% Full能够简单方便地理解每个表空间的大小和使用率。
 
 
 
同样还有几个列能用于了解表空间的类型，例如DMS或SMS，以及CIO/DIO是否启用。
 
 
 
 
 
3.3 动态SQL监控(D)
 
 
 
图4.动态SQL监控
 
 
 
 
动态SQL监控模式提供了每一个缓存的SQL语句的详细信息。用户也可以用这个监控模式给指定查询生成db2expln和db2exfmta。
 
 
 
执行次数(Num Execution) 和平均执行时间(Avg ExecTime) 可用于了解指定查询执行了多少次以及平均运行时间是多少。平均CPU时间(Num Execution)可用于与平均执行时间(Avg ExecTime)进行比较，以了解花在CPU活动上的时间百分比，或花在等待锁或I/O上的大部分时间。平均执行时间(Avg CpuTime) 
 
 
 
读取行和写入行对于理解查询的行为很有用。例如，如果用户看到一个select查询与大量的写入关联，这可能表明该查询可能存在排序（哈希连接）溢出，需要进一步调整以避免临时空间中的数据溢出。
 
 
 
db2top工具还计算了数据、索引和临时l_reads的命中率(Hit%)，以帮助用户轻松定位出是否需要调整缓冲池大小。平均每次执行排序(AvgSort PerExec) 和排序时间(Sort Time)是两个很好的指标，可以显示执行期间完成了多少排序。
 
 
 
db2top工具还提供了生成db2expln或db2exfmt报告的功能，而无需手动运行命令。通过在动态SQL监控模式下输入大写L，它将提示您输入SQL对应的哈希字符串。SQL哈希字符串是在表的第一列中显示的字符串，例如“00000005429283171301468277”。用户可以复制该字符串并将其粘贴到提示中，然后单击Enter，如图5所示：
 
 
 
图5.动态SQL监控模式-查询文本
 
 
 
 
然后，选择此屏幕上的e选项生成db2expln输出，或者选择x选项生成db2exfmt输出（如果explain.ddl已导入数据库）。
 
 
 
如果解释表不存在或与当前使用schema不同，将显示一个空屏幕。如果需要，用户可以执行以下命令生成解释表：
 
 
 
 
3.4 会话监控 (l)
 
图6.会话监控
 
 
 
 
会话监控模式提供每个应用程序会话的详细信息。第一列显示Application Handle，以下三列：Cpu%Total、IO%Total、Mem%Total表示此应用程序正在使用的资源的百分比。在大多数情况下，每个会话表示来自应用程序端的一个连接。
 
 
 
列Application Status和一些读写行的统计信息显示在这些列之后。用户还可以在此屏幕上看到LocksHeld，Sorts(sec)和LogUsed信息。当事务日志空间不足时，列LogUsed信息可能会对用户有所帮助。通过使用这个监视元素，用户可以了解哪些应用程序在占用更多的日志空间。
 
 
 
会话监控模式下包含的信息与用户在数据库监控模式下可以看到的信息类似，但会话监控模式下的信息适用于每个应用程序。通常情况下，最好把不同监控模式下的数据组合起来进行性能分析。例如，通过查看会话监控模式和动态SQL监控模式，可以进一步分析显示在数据库监控模式的大量读取的问题，以便把问题涉及范围缩小到特定的应用程序或SQL。
 
 
 
3.5 缓存池监控(b)
 
图7.缓存池监控
 
 
 
 
在此监控模式下，db2top提供有关每个缓冲池利用率的信息。用户可以看到缓冲池的一些基本信息，比如读取、写入和大小，还可以看到更高级的矩阵，如Hit Ratio%(缓冲池命中率)和(Async Reads%)。
 
 
 
一般来说，缓冲池命中率可用如下公式计算：
 
 
 
 
对应文本：
 
1 - ((pool_data_p_reads + pool_xda_p_reads + 
 
  pool_index_p_reads + pool_temp_data_p_reads 
 
  + pool_temp_xda_p_reads + pool_temp_index_p_reads )
 
  / (pool_data_l_reads + pool_xda_l_reads + pool_index_l_reads + 
 
  pool_temp_data_l_reads + pool_temp_xda_l_reads 
 
  + pool_temp_index_l_reads )) * 100%
 
 
 
3.6 锁监控(U)
 
 
 
图8.锁监控
 
 
 
 
锁定问题是应用程序诊断过程中最常见的问题之一。使用db2top工具，用户可以轻松列出应用程序中的锁。
 
使用db2top分析锁等待问题也更容易。下面的图9、10和11是在db2bp应用程序正在等待另一个db2bp会话的测试场景中获取的。
 
 
 
图9.锁等待--Application status
 
 
 
 
在图9中，第一列Agent Id(State)中列出了两个代理（代理24和代理9）。你可以在第三列Application Status(应用程序状态)中看到，其中一个代理（代理24）处于锁定等待状态(Lock Waiting status)。
 
 
 
图10.锁等待--Lock status
 
 
 
 
如果用户希望在锁监控模式下中看到更多信息，通过按键盘上的左箭头“←”，会显示更多的列，如图10所示。在锁状态列(Lock Status)中，除一个锁外，所有锁都处于已授权状态(Granted status)：“-”状态的锁是阻塞的锁。在锁模式列（Lock Mode）中，显示了包括请求的锁模式(S)和正在保持的锁（IX）等。
 
 
 
图11.锁等待--Table name
 
 
 
 
如图11所示，在这个特别的例子里，代理24正试图请求表TAOEWANG.T1的S锁，可它已被持有TAOEWANG.T1表上IX锁的代理9锁定。
 
 
 
在锁监控模式中db2top提供的另一个非常有用的特性是锁链分析。如果问题涉及到多个应用程序，那么想找出锁等待关系就不那么容易。因此为了使用户更方便地理解应用程序之间的锁关系，db2top工具提供了一个有用的特性：动态地绘制锁链。
 
 
 
通过输入大写L可展示锁链，如图12所示：
 
 
 
图12.锁等待--Lock chain
 
 
 
 
 
 
3.7 表监控 (T)
 
 
 
图13.表监控
 
 
 
 
表监控模式显示数据库中的表信息。在当前时间内未被访问的空闲表以白色显示。正在访问（活动）的表以绿色显示。
 
 
 
列Delta RowsRead(Written)/s表示在使用时间内读写的行除以时间间隔。这个数字显示各表在当前时间的使用频率。
 
 
 
另外还有关于表本身的信息。列数据页（Data Pages）和索引页（Index Pages）表示表中有多少页。表类型（Table Type）和表大小（Table Size）对于理解表的属性也很有用。
 
 
 
另一个重要的列是Rows Overflows/s，它表示在当前时间内每秒多少行数据发生了溢出。溢出的行会产生数据碎片。如果这个列数值过高，用户应该通过使用REORG重新构建表来清除碎片，以提高表的性能。
 
 
 
3.8 瓶颈监控 (B)
 
 
 
图14.瓶颈监控
 
 
 
 
瓶颈分析是DBA不能忽视的过程。他们想知道哪个代理（应用程序）严重限制了整个DB2系统中特定组件的性能或容量，而db2top通过显示关键服务器资源的主要消费方，可解决这个问题。而且工具中会显示消耗每个类别大部分资源的代理ID。
 
 
 
标题“Bottleneck”下的方框用于各种数据库操作的时间分析：
 
 
 
The elapsed time used to calculate the percentage of each operation = (wait_lock_time + sort_time + bp_read_time + bp_write_time + async_read_time + async_write_time + prefetch_waite_time + direct_read_time + direct_write_time).
 
{用于计算每个操作的百分比所用的时间= (等待锁定时间+排序时间+bp读取时间+bp写入时间+异步读取时间+异步写入时间+预取等待时间+直接读取时间+直接写入时间) }
 
 
 
下列是每个操作的预估百分比：
 
· wait lock ms: (wait lock time)/(elapsed time) = 80%
 
· sort ms : (sort time)/(elapsed time) = 0
 
· bp r/w ms: (buffer pool read and write time)/(elapsed time) = 10%
 
· async r/w ms: (async read and write)/(elapsed time) = 6%
 
· pref wait ms: (prefetch_waite_time)/(elapsed time) = 2%
 
· dir r/w ms: (direct read and write time)/(elapsed time) = 2%
 
· 
 
“Bottleneck”瓶颈监控模式下的主体显示每个服务器资源中哪个代理是瓶颈。
 
 
 
“Bottleneck”瓶颈监控模式下的第一列，Server Resource，展示监控的服务器资源类型：
 
· Cpu: Which agent consumes the most CPU time.
 
· SessionCpu: Which application session consumes the most CPU time.
 
· IO r/w: Which agent consumes the most I/O read and write.
 
· Memory: Which agent consumes the most memory.
 
· Lock: Which agent is holding the most locks.
 
· Sorts: Which agent has executed the biggest number of sorting.
 
· Sort Times: Which agent consumes the longest sorting time.
 
· Log Used: Which agent consumes the most log space in the most recent unit of work.
 
· Overflows: Which agent has the most number of sort overflows.
 
· RowsRead: Which agent has read the most number of rows of records.
 
· RowsWritten: Which agent has written the most number of rows of records.
 
· TQ r/w: Which agent has sent and received most number of rows on table queues.
 
· MaxQueryCost: Which agent has the max SQL execution time estimated by the compiler.
 
· XDAPages: Which agent has the most number of pages for XDA data (available in V9.1GA and after releases).
 
 
 
例如：图14显示了代理683，即db2bp（DB2后端进程），显然是瓶颈。
 
至于内存使用瓶颈分析，您可以在图14中看到以下内容：
 

这表明在所有的代理中，代理17，即另一个db2bp（DB2后端进程），消耗了最多的内存：17.11%，共计832.0K。
 
 
 
4.其他
 
db2top工具的设计理念和DB2 Health Monitor工具大不相同。DB2 Health Monitor设置了一组阈值，并持续的监控这些矩阵，一但达到阈值，DB2 Health Monitor则会触发告警机制。db2top是一款可以周期地获取快照基础工具，它让用户无需分析快照文件而直观地得出结果。
 
 
 
db2top能让用户能够在文本构成的图形界面中监控DB2系统。它可用于确定DB2在一段时间的运行中内是否存在问题，并缩小问题的根因范围。用户会发现在监控实时系统和调试日常工作中的问题方面，这是一个很实用的工具。

 
 
点击蓝字
 

 
关注我们
 
AI TIME欢迎每一位AI爱好者的加入！
 
top-k操作（即从分数集合中找到k个最大或最小元素）是一个重要的机器学习模型组件，被广泛用于信息检索和数据挖掘中。但是，如果top-k操作是通过算法方式（例如使用冒泡算法）计算的，则无法使用现在流行的梯度下降算法以端到端的方式训练所得模型。这是因为这些计算方式通常涉及交换索引，无法用来计算其梯度。换句话说，从输入数据到该元素是否属于前k个集合的指标向量的对应映射是不连续的。
 
为了解决这个问题，我们提出了一个平滑的近似操作，即SOFT top-k运算符。具体来说，我们的SOFT top-k运算符将top-k运算的输出近似为最优传输问题的解。然后，我们基于最优传输问题的KKT条件快速地估算SOFT运算符的梯度。我们将提出的算子应用于k nearest neighbors分类和beam search算法，并通过实验展示了性能的提高。
 

 
谢雨佳：本科毕业于中国科学技术大学少年班学院，现为佐治亚理工学院CSE系第五年博士生，导师为查宏远教授和赵拓教授。她的研究方向主要为最优传输理论和端到端学习。
 

 
一、动机：如何将Top K 嵌入到深度学习框架中？
 
k nearest neighbors （kNN） classifier 是一个非常常见且实用的分类方法。具体来说，假设有很多已知label的template data，以及一个未知label的query data，我们可以将未知的query data与其他image相比，得到比较相似的k个图片，将其称为k nearest neighbors，并将这些 neighbors的label作为该未知data的label。对于image data，一个自然的做法是使用特征抽取网络(feature extraction)将这些image投影到一个embedding space里，并在这个embedding space中做kNN以得到对未知data的预测。然后我们最小化损失函数来更新特征抽取网络中的参数。但是，该模型框架的缺点在于：由于需要进行的top-k操作不可微，因此不能通过梯度下降法或者随机梯度下降法实现参数优化。
 

 
图1  深度k近邻网络结构示意图

 
为什么top-k 不可微？考虑一个top-k算法，比如，bubble，heap或者quick sort partition这些算法，实则是不断置换输入变量（input scores）的索引（indices），这个置换索引的操作是不可微的。从另一个角度出发，输入为“4 1 2 3 0 1 2”，然后得到排名第一的元素，若用一个identical director表示的话为“1 0 0 0 0 0 0”，当输入变为“5 3 1 0 2 2 1”时，输出不变。这说明，top k 操作本质上是一个分段常数映射（piecewise constant function），其梯度要么为0，要么不存在。这也进一步解释了，为什么该模型框架不能通过梯度下降法或者随机梯度下降法实现参数优化。基于此，讲者旨在设计一种能实现可微的top k operator。
 

 
图2  研究top-k 的深度学习网络的目标

 
二、如何使Top-K问题可微？
 
首先，将实现可微的top-k operator问题看作是一个最优运输问题，即把一个分布的mass运输到另一个分布上，并使运输成本最小。比如，有两个分布和，以及成本矩阵，那么问题就转化成如图中所示的优化问题，就代表了最终的运输计划。
 

 
图3  最优运输问题

 
回到top-k的问题上，假设现在有六个输入值，希望求取top-2的元素。对此，我们可以构造这样一个最优运输问题，其中是输入值的经验分布（在这六个值上，每个值上分布1/6的mass），是参数为k/N的伯努利分布。也就是说，在0上放置2/3的mass，在1上放置1/3的mass。根据最优运输的规则，最优运输方案 (Optimal Transport Plan, OT plan)就是将较大的两个数运输到1的位置，将较小的四个数运输到0的位置。基于此，可得到最优运输方案的matrix，其第二行就是所求的指示向量（indicate vector），若向量元素为1则表示该数为top k elements，为0时则不是。
 

 
图4  将top-k问题视作最优运输问题

 
其次，怎样让top-k问题可微？讲者提出在上述的最优运输方案的基础上增加一项正则熵（entropy regularization）。主要是因为，最优运输问题是一个线性规划的问题，则其最优解几乎一定在可行域的顶点上，也就是说当输入（X）发生变化的时候，最优解会从可行域的一个顶点跳跃到另一个顶点上，这个过程是不可微的。增加了正则熵之后，得到最优解将是可行域的内点，当X发生变化时，也是平滑变化，这就可以使从X→的映射实现可微。
 

 
图5  top k 问题可微——增加正则熵

 
在很多应用中，不仅需要知道哪些元素是top-k，并且还需得知 top-k中k个元素的排序。因此，讲者做了如图6所示的修改，分布不再是伯努利分布，而是在0的位置上依旧分布2/3的mass，然后在1和2上分别分布1/6的mass。由此得到OT plan的matrices，并表示出哪一个得分最大，哪一个得分第二大。
 

 
图6  top k 中k个元素的排序

 
具体地说，如何求解带有正则熵的OT plan问题？讲者介绍了一种专门求解带有正则熵的OT plan问题的算法——Sinkhorn 算法，该算法可循环迭代且线性收敛，同时算法的迭代次数与N无关，这说明算法的时间复杂度是O(N)。另外，为了将top-k嵌入到深度学习框架中，并使其可微，就不仅需要求出top-k 的元素是什么，还需要知道如何求解top-k 的梯度。一般来说，求导就是进行误差向后传播（back propagation），可直接使用自动微分法。但由于Sinkhorn 算法是一个迭代算法，因此在forward pass中，需要将迭代的中间变量都存到内存中，这不仅对内存的负担很大，而且求梯度的过程也会比较慢。因此，这里直接使用梯度的闭式解来求解，即在forward pass中求得top-k之后，通过简单的矩阵操作可得到梯度。
 

 
图7  梯度的 closed-form图解

 
由于是一个优化问题的最优解，因此与X的关系被KKT条件约束，由图8的推导，可得到top-k operator的闭式解。
 

 
图8  top k operator的梯度求解

 
但是，增加正则熵后得到的最优解并不是准确的top-k operator（由于正则项引入了bias），那么该如何量化这个bias？讲者通过对比增加了正则熵的与没有加正则熵的，证明该差别受限于下述表示，且当系数越来越大时，得到的解会越来越平滑。
 

 
图9  top k operator的梯度求解

 
三、实验验证
 
1）图像分类实验研究
 
通过与baselines对比可知，该方法可以有效提高分类精度。相比于文章中采用的基于kNN的端到端训练，作者着重强调了两个baselines，即kNN+pretrained CNN以及CE+CNN，前者使用两阶段训练：先用交叉熵来训练一个神经网络来作为特征提取器，将image编码到embedding space中，然后在embedding space中做kNN以得到一个预测；后者是直接结合交叉熵与CNN实现分类，结果如图10所示。
 

 
图10  图像分类结果对比

 
2）自然语言生成实验研究
 
在生成句子时（inference stage），需要模型一个字一个字生成（beam search），即从起始词开始，模型会选择前k个likelihood较大的词作为候选词，循环反复，最终选择likelihood最大的句子作为output。但在训练阶段，是利用ground truth sequence来训练模型，但问题是模型没有利用自己生成的词来进行训练，因此开始时模型生成的词如果有一点误差，在后续inference 阶段误差会被很快放大。
 

 
图11  Beam search training 算法

 
如果能够将beam search嵌入到training阶段，模型的training阶段和inference阶段就是完全一致的，这个问题就可以迎刃而解。然而由于beam search的每一步都需保留前k个likelihood最大的词，这是典型的top-k 操作，如何能将beam search嵌入到training阶段？
 
采用讲者提出的可微top-k operator实现beam search，即在每一步有Nk个选择以及vector of likelihood，将vector of likelihood放到sorted top-k operator中取top-k得到matrixes，将这个matrixes与所有词的embedding matrix相乘得到下一步的input，循环进行以得到一个likelihood最大的sequence，与ground truth sequence进行比较，实现training。
 
在WMT14的数据集上的实验，证明了加入beam search training的模型实现了不小的提高。
 

 
图12  嵌入top-k 的beam search training 网络和
 
基于beam search的实验验证
 
相关资料
 
文章下载二维码
 
Full paper: Differentiable Top-k with optimal transport, NeurIPS 2020
 

 
参考文献
 
Cuturi M . Sinkhorn Distances: Lightspeed Computation of Optimal Transportation Distances. NIPS, 2013.
 
https://dl.acm.org/doi/10.5555/2999792.2999868
 
Cuturi, M., Teboul, O. and Vert, J.-P.：Differentiable ranking and sorting using optimal transport. NIPS,2019.
 
 
 
  e           m     t

 
往期精彩
 
 AI                i

 

 
     
 
整理：刘美珍

 
审稿：谢雨佳
 
排版：岳白雪
 
AI TIME欢迎AI领域学者投稿，期待大家剖析学科历史发展和前沿技术。针对热门话题，我们将邀请专家一起论道。同时，我们也长期招募优质的撰稿人，顶级的平台需要顶级的你！
 
请将简历等信息发至yun.he@aminer.cn！
 
微信联系:AITIME_HY
 
AI TIME是清华大学计算机系一群关注人工智能发展，并有思想情怀的青年学者们创办的圈子,旨在发扬科学思辨精神，邀请各界人士对人工智能理论、算法、场景、应用的本质问题进行探索，加强思想碰撞，打造一个知识分享的聚集地。
 

 
更多资讯请扫码关注
 
 
 
（直播回放：https://b23.tv/qmP3rC）
 
（点击“阅读原文”下载本次报告ppt）