性能调优学习记录

记录一些，具体还是应该多从实践中学习，总结。

一  从阿里技术微信公众号记录:

基本方法：

1. 准备阶段：主要工作是是通过性能测试，了解应用的概况、瓶颈的大概方向，明确优化目标；
       --个人理解是了解应用的架构，部署方式，业务运行情况等背景信息 （例如服务是多态机器集群部署，主要是干嘛干嘛的，每天的访问量多少，跟什么外部服务有交互，交互量多少，服务的重要等级等待），明确需要优化什么（是提供更高的tps还是对数据库资源更少占用，cpu过高还是内存，网络过高等)
2. 分析阶段：通过各种工具或手段，初步定位性能瓶颈点；
     个人理解这部分很依赖个人经验和能力，有一些基本方向  和工具可以参考，后面重点说明
3. 调优阶段：根据定位到的瓶颈点，进行应用性能调优；  个人理解这部分就根据分析结果和个人能力解决问题，需要满满积累
4. 测试阶段：让调优过的应用进行性能测试，与准备阶段的各项指标进行对比，观测其是否符合预期，如果瓶颈点没有消除或者性能指标不符合预期，则重复步骤2和3。  
   
   

2，3，4 是一个不断分析，解决，验证的过程重复直到效果满意

步骤2 的工具和基本方法：

cpu：  cpu利用率，cpu负载，cpu上下文切换，线程数量，等待线程数量

内存： 

磁盘文件: iostat，pidstat

网络： 

命令记录 ：

1. CPU：top、vmstat、pidstat、sar、perf、jstack、jstat；
2. 内存：top、free、vmstat、cachetop、cachestat、sar、jmap；
3. 磁盘：top、iostat、vmstat、pidstat、du/df；
4. 网络：netstat、sar、dstat、tcpdump；
5. 应用：profiler、dump分析。

二。其他整理

cpu高处理方法：

查看cpu核心数量

cat  /porc/cpuinfo

vmstat    free    top -Hp pid

jstack  pid 查看进程信息里，搜索高占比的线程

内存高 可以看heap dump

网络和io高需要具体定位到哪个线程和代码导致，然后修改代码。iostat 好像需要安装,ifstat iftop

三。拷贝网上例子,不是我遇到的，只是拷贝下来学习的：

3.1 ：IO高例子：

原文地址：http://www.cnblogs.com/cenalulu/archive/2013/04/12/3016714.html

前言：

在一般运维工作中经常会遇到这么一个场景，服务器的IO负载很高（iostat中的util），但是无法快速的定位到IO负载的来源进程和来源文件导致无法进行相应的策略来解决问题。

这个现象在MySQL上更为常见，在5.6（performance_schema提供io instrument）之前，我们通常只能猜到是MySQL导致的高IO，但是没法定位具体是哪个文件带来的负载。

例如是ibdata的刷写？还是冷门ibd的随机读取？

本文就将介绍一个比较简单的定位IO高负载的流程。

工具准备：

iotop: http://guichaz.free.fr/iotop/

pt-ioprofile:http://www.percona.com/downloads/percona-toolkit/2.2.1/

---

Step1 : iostat 查看IO情况

 iostat -x 1 查看IO情况，从下图可以看到dfa这个磁盘的IO负载较高，接下来我们就来定位具体的负载来源

---

 Step2： iotop定位负载来源进程

 iotop的本质是一个python脚本，从proc中获取thread的IO信息，进行汇总。

从下图可以看出大部分的IO来源都来自于mysqld进程。因此可以确定dfa的负载来源是数据库

---

Step3 pt-ioprofile定位负载来源文件

 pt-ioprofile的原理是对某个pid附加一个strace进程进行IO分析。

以下是摘自官网的一段警示：

 However, it works by attaching strace to the process using ptrace(), which will make it run very slowly until strace detaches. In addition to freezing the server, there is also some risk of the process crashing or performing badly after strace detaches from it, or indeed of strace not detaching cleanly and leaving the process in a sleeping state. As a result, this should be considered an intrusive tool, and should not be used on production servers unless you are comfortable with that.

通过ps aux|grep mysqld 找到 mysqld进程对应的进程号，通过pt-ioprofile查看哪个文件的IO占用时间最多。

默认参数下该工具展示的是IO占用的时间。

 

 对于定位问题更有用的是通过IO的吞吐量来进行定位。使用参数 --cell=sizes，该参数将结果已 B/s 的方式展示出来

从上图可以看出IO负载的主要来源是sbtest （sysbench的IO bound OLTP测试）。

并且压力主要集中在读取上。