性能(调优)三种吹毛求疵的行为

做个性能调优，也看过别人的性恩调优，我认为有三种吹毛求疵的性能调优行为，害人害己，有必要拿出来说一下。

 

第一个是片面虚拟机调优： 调优行为是个系统行为，能起到立竿见影的效果的有数据库调优，机器升级，或者架构上的调整，如引入缓存，去掉同步锁，采用异步和并发等。虚拟机调优在我看来，是调优的最后一步，也就是说，其他办法你都用了但你老板还要你做的更好，那就只好采用虚拟机调优。但虚拟机调优真的有用么?虚拟机的参数设定默认是平衡的，调优无非是根据你的业务情况来调整，但通常系统业务都非常复杂，采用这种方式能兼顾这钟业务，但兼顾不了那种业务，所以我认为虚拟机调优用处不大。与其花时间底层搞虚拟机调优，还不如业务层看看。之所以有些人爱提JVM调优，无非是这些人非你系统的人，如专门调优咨询，或者公司的平台部的，他们只能通过这种方式去调优。

 

第二个片面行为是吹嘘产品每天能处理上亿的量到上百亿量： 我认为只要系统设计是水平扩展的，那要处理多少量都可以，无非是增加机器而已。每天处理量多，只能证明其稳定可靠罢了。不能用这个作为噱头证明其性能多好以误导潜在的使用者

 

第三个片面强每秒吞吐量，但却没有提供CPU，磁盘等物理设备的消费。假如同样俩个产品，你的比别人快俩倍，但消费的CPU也比别人多俩倍，那在某些场景下，你的产品也许并无优势。潜在的使用者如果使用了你的产品而影响了其他系统，这就不好了，比如我前段时间调优，目标大概是20秒内业务需要处理100万数据。虽然后来调优成功了，但CPU，磁盘都达到了峰值，如果按照这个调优思路上线，会影响其他系统的。 所以谈及性能的时候，也把CPU，磁盘列出了吧，就一个sar命令，观察一下看看就行了。我在帮助中国移动研究院一个项目中做消息中间件调查，这些指标里就必须包括运行消费的硬件，如CPU（系统，用户），磁盘（读写），带宽（输入，输出）等

 

 

 

 

后两个有一定道理，
第一个就扯了，，，一个不合适的jvm参数或是一个恶心的代码写法，导致gc问题严重甚至d宕机，你还业务调个毛啊。

调优的第一步是收集性能数据，找到瓶颈，分析列出可能影响性能的因素从重要到次要1234，一个个去解决，不管影响性能的因素是业务逻辑的本身，还是业务实现，还是不合适的数据计算中间结构还是数据库表关系、索引，还是虚拟机的参数配置，甚至是操作系统的参数设置。很多场景，jvm和os的参数设置比你所谓的业务调优更要有效，而且还不需要去改项目的代码。你觉得这个不爽、没用、兼顾不了，纯粹是你能力不足的问题。

严重同意楼上的，在硬件不可更改的情况下虚拟机调优是一个很有用的手段

先搞懂故障诊断和性能调优的区别, performace trouble shooting 和 performace tuning 的区别先.

你说的导致宕机问题属于故障诊断范畴，这个你认为调整JVM性能参数就解决了，笑话。先把概念搞清楚在喷也好啊

头一次听说JMV调优会比应用调优更有效，你举俩个例子出来吧。我文章里已经举了好几个例子，业务和架构调优，如数据库优化，Cache等。你也说几个场景JVM调优效果更好的情况吧。期待你用例子来证明你的观点。

一般情况下，调优路径 是从上到下，即先业务，后系统，然后应用服务器，然后虚拟机，最后os。
故障诊断则路径相反。

我对你本人的判断就是有点java皮毛经验，可真没有干过调优的事情，更没有系统级的调优了。

看看我给kimmking的回复，我不否认虚拟机调优，但我认为JVM调优它是最后的手段也是效果最不明显的手段。花点精力自上到下的调优才会事半功倍，并不是你说的很有用的手段

性能瓶颈 不等于 故障！

我举宕机例子，只是为了说明影响大。

调优只是提高系统服务能力的一个手段，不是目的。
调优的必要性在于系统的性能存在问题，或是针对业务的预期增长存在问题。
（扩容、规划机器的事儿，咱不考虑）

如果系统没有任何问题，去调优做什么呢？
这时调优本身就变成吹毛求疵了。

你也说了 调优是件系统的事儿，
但从业务实现、技术设计这些研发层面去考虑问题，而不考虑部署和实施，明显是不够的。

你说的对，帖子只是说明片面强调虚拟机调优对于系统调优来说，效果微乎其微。但我看到太多人的去专研虚拟机调优了

对虚拟机或操作系统的调优，“效果微乎其微”？

这个你说了不算，我说了也不算，谁说的都不算，实践中动手试试才知道。
而且，根据我们的经验，有些场景下，很有用。