本文共 2563 字，大约阅读时间需要 8 分钟。
Linux系统下的性能问题不太好解决，尤其是存储相关的问题。工作中面临这些的性能问题是比较多的，大部分是用户反馈的。为了能及时高效地解决性能问题，
迫切地需要对性能问题解决方面有个系统的，深入的探索。
性能问题跟稳定性问题相比，还是有很多自己独特的地方的。总结起来，性能问题有如下几个特点：
1：性能问题的评判标准多带有主观性的
稳定性问题基本上是系统出现bug了，导致某方面功能不正常。那这个肯定是必须解决的，而且评判标准也比较简单，就是解决后，该bug不会再出现了。
性能问题就不一样了，有些时候我们碰到的性能问题，其在系统里面的表现都是很正常的行为，并不是发生了什么bug。
举例解释：
比如用户执行zip解压缩性能测试时，发现解压缩耗时长，报问题jira了。然后经过我定位是解压缩的时候，系统自身的整体工作负载就比较重（执行uptime命令，由Loadavg指标可以看出）。
那在重负载情况下，解压缩肯定耗时了。
还有测试会报解压缩耗时问题给开发，但这个耗时得有个合理的评判标准，要仔细选好基准版本进行性能比较。
2：存储性能问题很多时候是系统内多方面因素造成的
稳定性问题大多数都反映在系统内部某个模块出了问题，修复该模块的缺陷，该问题就没有了。
性能问题很多时候则不是这样，用户反馈的问题，从表面看比如是zip解压缩性能差，需要解决该问题。但是仔细分析后，会发现zip解压缩线程在工作时，其性能会受到多方面的因素影响的，
比如手机Android系统的cpu，内存，存储三大块都会影响解压缩性能，更不用说cpu里面有task调度和上下文切换次数等，存储里面有文件系统层，块设备层和存储芯片层等，这些子项目，子模块都对最终对解压缩性能产生不同的影响的。
所以性能问题很多时候是系统的多方面因素综合影响造成的，需要仔细地排查各方面的因素，从中找到导致性能差的若干因素，并优化它们。
3：性能问题解决具有普适性，反映的是软件基础层面的东西。
之前老是听到别人对性能工作的一些误解，比如觉得性能工作只有大公司，大厂才会去花精力去做，小公司做的都是解决稳定性问题，性能工作不需要。
而我觉得性能问题解决和优化方面的工作其实更多体现的是软件基础层面上的东西。比如分析cpu调度，内存分配和存储管理对Linux单进程工作性能的影响，这些都是计算机系统中最基础层面的优化工作。
正是因为做的基础层面工作比较多，所以才跟操作系统内核联系比较紧密的。
各个行业，无论是大公司，还是小公司都是需要会这种基础层面工作的人加盟的，并且性能与稳定性工作也是密不可分的。
举个例子：
之前呆的一家小公司，做Android车载机。客户提出的需求是在车载机发声时，与此同时无论怎么操作车载机，都不能有pop音出现（做过audio工作的，应该知道pop音会影响到产品的视听效果）。
而pop音如果想彻底干净地根除它，一方面也得对Linux系统的性能优化工作有所熟悉。因为有audio进程在工作时，它在任何时候如果发生进程调度延迟时，都会出现pop音。
而进程的调度延迟方面原因则跟系统的内存，cpu调度等这些基础层面性能优化工作密切相关的。所以小公司也需要会性能优化的人加盟的。
再举个例子：
现在出货低端手机，量大点也是很赚钱的。因为低端机的硬件器件成本低。但是低端机往往都是内存和外存容量小，这种手机再配上现在复杂的吃硬件的操作系统，比如Android。那么如果不做性能优化工作，那么低端机可能用户就根本用不了，一用就各种手机卡顿现象出来了。所以低端机，便宜货的消费电子产品更需要会性能优化的人才加盟。
4：性能问题的解决有时候会带点残缺性，不会那么完美。
稳定性问题解决方面，通常是系统哪块出bug了，ok，解决搞定它，这样只要认真钻研，解决完后，都会对系统不会有任何负作用了。
但是性能问题有时候不是这样的，比如对于低内存手机，需要减小Linux内核的预读窗口，因为预读窗口大了，会带来内存回收方面的压力，这对低内存手机工作性能不好。
但是调低了预读窗口，那么程序如果要进行大文件连续顺序读的话，那么比较低的预读窗口会降低顺序读的性能。
所以性能问题的优化解决往往要评估是否对系统哪些场景下的性能有负作用，并结合自己的产品业务特点，评估部署该性能优化方案带来的收益是否可以大大抵消该负作用的影响。
5：有些疑难性能问题地解决更能锻炼提升对整个模块架构层面的理解能力。
有些性能问题是很难解决的，因为它反应的是某模块架构层面的局限性东西。要想解决该问题，就得优化该模块的架构体系了。
比如ext4文件系统的因jbd2和fsync强耦合性导致的fsync慢问题，该fsync慢主要是因为jbd2的架构设计问题，导致jbd2工作在开启延迟分配的系统中会出现单次工作比较耗时。
然后jbd2工作耗时，会导致fsync有时候不得不停下来等待jbd2工作完成后，fsync才能成功结束自己的工作。
手机还是想用order模式的话，就得解决这个jbd2和fsync强耦合性架构问题了。
这个问题一旦解决了，那么会对整个存储系统的日志工作机制和ext4文件系统架构体系都会有个深刻地理解和掌握的。
目前，社区正由ext4 owner推进解决该架构缺陷问题。
针对上面特点1：
性能问题定位解决时首先要有个科学合理的评判标准，比如针对静态和动态性能测试case，有不同的评判标准。
还是拿zip解压缩性能测试case为例：
静态测试case就是类似于手机系统完全没有其他后台任务在跑的情况下的benchmark跑分。
动态测试case类似于上面模拟不同用户使用手机的场景，在后台进行内存或者IO加压的情况下，测试zip解压缩性能。
所以要分别针对静态和动态测试case制定不同的性能问题评判标准。
针对上面特点2：
要针对不同的性能问题，研究不同的问题解决方法，并列出问题排查check list。
比如手机里面的zip解压缩耗时长这个性能问题，经过我的分析判定是单线程的工作耗时性能问题。那么只要能找到导致单线程工作耗时长的一些因素，并优化它们即可。
详细定位分析思路见另外一篇文档：linux系统单线程工作耗时性能解析。
转载地址：http://lkrvb.baihongyu.com/