1、Redis连接池
说明：
- 最大连接数：连接池配置的最大连接数
- 活跃连接数：当前处于活动状态的连接数
- 空闲连接数：当前处于空闲状态的连接数
2、QPS
说明：query per second
3、执行时间
说明：执行一次Redis命令的时间
4、等待连接线程数
说明：等待获取连接的线程数
5、每秒请求错误数
说明：执行Redis命令的错误数
2、Linux下一些常用的查看性能的命令
2.1 top
第二行 分别显示：total进程总数、 running正在运行的进程数、 sleeping睡眠的进程数、stopped停止的进程数、 zombie僵尸进程数。
第三行
分别显示：
%us 用户空间占用CPU百分比、
%sy 内核空间占用CPU百分比、
%ni 用户进程空间内改变过优先级的进程占用CPU百分比、
%id 空闲CPU百分比、
%wa 等待输入输出（I/O）的CPU时间百分比 、
%hi指的是cpu处理硬件中断的时间、%si指的是cpu处理软中断的时间 、
把可以延迟的处理从硬中断处理程序独立出来，这样这个处理可以在开中断的情况下运行，这个处理就是软中断。可见，软中断的这种脱离可以大大缩短硬中断的响应时间，对于很多实时应用来说及其重要。
%st用于有虚拟cpu的情况，用来指示被虚拟机偷掉的cpu时间。
通常id%值可以反映一个系统cpu的闲忙程度。
2.2 vmstat
r 表示运行队列(就是说多少个进程真的分配到CPU)
b 表示阻塞的进程,这个不多说，进程阻塞
swpd 虚拟内存已使用的大小，如果大于0，表示你的机器物理内存不足了，如果不是程序内存泄露的原因，那么你该升级内存了或者把耗内存的任务迁移到其他机器。
判断CPU是不是瓶颈
1.使用率
2.上下文切换
3.软中断
4.队列（运行在cpu上的线程和等待CPU的线程之和）
2.3 netstat 端口 -> 进程
2.4 iostat
avgqu-sz：平均I/O队列长度.即 delta(aveq)/s/1000 (因为aveq的单位为毫秒).
await： 平均每次设备I/O操作的等待时间 (毫秒).即 delta(ruse+wuse)/delta(rio+wio)
svctm： 平均每次设备I/O操作的服务时间 (毫秒).即 delta(use)/delta(rio+wio)
util：一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的，即 delta(use)/s/1000 (因为use的单位为毫秒)
1.执行“top”命令：查看所有进程占系统CPU的排序。极大可能排第一个的就是咱们的java进程（COMMAND列）。PID那一列就是进程号。
top 或者jps
ps aux | head -1;ps aux |grep -v PID |sort -rn -k +4 | head -202.执行“top -Hp 进程号”命令：查看java进程下的所有线程占CPU的情况。
top -Hp pid3.执行“printf "%x\n 10"命令 ： 后续查看线程堆栈信息展示的都是十六进制，为了找到咱们的线程堆栈信息，咱们需要把线程号转成16进制。 例如, printf "%x\n 10145"-》打印：a，那么在jstack中线程号就是0xa.
printf "%x\n" 10145
jstack 7 | grep -A 40 684.执行 “jstack 进程号 | grep 线程ID” 查找某进程下 -》 线程ID（jstack堆栈信息中的nid）=0xa的线程堆栈信息。 如果“"VM Thread" os_prio=0 tid=0x00007f871806e000 nid=0xa runnable”， 第一个双引号圈起来的就是线程名， 如果是“VM Thread”这就是虚拟机GC回收线程了
jstack 111 | grep 1011
jstack -l 65111 > jstack01.log5.执行“jstat -gcutil 进程号 统计间隔毫秒 统计次数（缺省代表一致统计）”，查看某进程GC持续变化情况，如果发现返回中FGC很大且一直增大-》确认Full GC! 也可以使用“jmap -heap 进程ID”查看一下进程的堆内从是不是要溢出了，特别是老年代内从使用情况一般是达到阈值(具体看垃圾回收器和启动时配置的阈值)就会进程Full GC。
jstat -gcutil 111 1000 1006.执行“jmap -dump:format=b,file=filename 进程ID”，导出某进程下内存heap输出到文件中。可以通过eclipse的mat工具查看内存中有哪些对象比较多。 以下是发现解决问题的具体流程。
jmap -dump:format=b,file=heap_1.hprof 1
