至于CPU瓶颈的定位工具，最有名也是最有用的工具就是perf，它是性能分析的第一步，可以帮我们找到系统的热点函数。就像人看病一样，只知道症状是不够的，需要通过医疗机器进一步分析病因，才能对症下药。
所以我们通过性能分析工具PMU或者其他工具去进一步分析CPU热点的原因比如是指令数本身就比较多，还是Cache miss导致的等，这样在做性能优化的时候不会走偏。
优化CPU的目标就是让CPU运行不受阻碍。
2. 如何定位IO瓶颈？系统IO的瓶颈可以通过CPU和负载的非线性关系体现出来。当负载增大时，系统吞吐量不能有效增大，CPU不能线性增长，其中一种可能是IO出现阻塞。
系统的队列长度特别是发送、写磁盘线程的队列长度也是IO瓶颈的一个间接指标。
对于网络系统来讲，我建议先从外部观察系统。所谓外部观察是指通过观察外部的网络报文交换，可以用tcpdump, wireshark等工具，抓包看一下。
比如我们优化一个RPC项目，它的吞吐量是10TPS，客户希望是100TPS。我们使用wireshark抓取TCP报文流，可以分析报文之间的时间戳，响应延迟等指标来判断是否是由网络引起来的。
然后可以通过netstat -i/-s选项查看网络错误、重传等统计信息。还可以通过iostat查看cpu等待IO的比例。IO的概念也可以扩展到进程间通信。
对于磁盘类的应用程序，我们最希望看到写磁盘有没有时延、频率如何。其中一个方法就是通过内核ftrace、perf-event事件来动态观测系统。比如记录写块设备的起始和返回时间，这样我们就可以知道磁盘写是否有延时，也可以统计写磁盘时间耗费分布。有一个开源的工具包perf-tools里面包含着iolatency, iosnoop等工具。
3. 如何定位IO瓶颈？应用程序常用的IO有两种：Disk IO和网络IO。判断系统是否存在IO瓶颈可以通过观测系统或进程的CPU的IO等待比例来进行，比如使用mpstat、top命令。
系统的队列长度特别是发送、写磁盘线程的队列长度也是IO瓶颈的一个重要指标。
对于网络 IO来讲，我们可以先使用netstat -i/-s查看网络错误、重传等统计信息，然后使用sar -n DEV 1和sar -n TCP,ETCP 1查看网路实时的统计信息。ss （Socket Statistics）工具可以提供每个socket相关的队列、缓存等详细信息。
更直接的方法可以用tcpdump, wireshark等工具，抓包看一下。
对于Disk IO，我们可以通过iostat -x -p xxx来查看具体设备使用率和读写平均等待时间。如果使用率接近100%，或者等待时间过长，都说明Disk IO出现饱和。
一个更细致的观察方法就是通过内核ftrace、perf-event来动态观测Linux内核。比如记录写块设备的起始和返回时间，这样我们就可以知道磁盘写是否有延时，也可以统计写磁盘时间耗费分布。有一个开源的工具包perf-tools里面包含着iolatency, iosnoop等工具。
4.如何定位锁的问题？大家都知道锁会引入额外开销，但锁的开销到底有多大，估计很多人没有实测过，我可以给一个数据，一般单次加解锁100 cycles，spinlock或者cas更快一点。
使用锁的时候，要注意锁的粒度，但锁的粒度也不是越小越好，太大会增加撞锁的概率，太小会导致代码更难写。
多线程场景下，如果cpu利用率上不去，而系统吞吐也上不去，那就有可能是锁导致的性能下降，这个时候，可以观察程序的sys cpu和usr cpu，这个时候通过perf如果发现lock的开销大，那就没错了。
如果程序卡住了，可以用pstack把堆栈打出来，定位死锁的问题。
5. 如何提⾼Cache利用率？内存/Cache问题是我们常见的负载瓶颈问题，通常可利用perf等一些通用工具来辅助分析，优化cache的思想可以从两方面来着手，一个是增加局部数据/代码的连续性，提升cacheline的利用率，减少cache miss，另一个是通过prefetch，降低miss带来的开销。
通过对数据/代码根据冷热进行重排分区，可提升cacheline的有效利用率，当然触发false-sharing另当别论，这个需要根据运行trace进行深入调整了；说到prefetch，用过的人往往都有一种体会，现实效果比预期差的比较远，确实无论是数据prefetch还是代码prefetch，不确定性太大，指望编译器更靠谱点。
小结性能优化是一项细致的工作，性能优化也是一个系统性工程。性能优化通常是在现有系统和代码基础上做改进，它并非推倒重来，考验的是开发者反向修复的能力，而性能设计考验的是设计者的正向设计能力，但性能优化的方法可以指导性能设计，两者互补。