提高系统性能其实是平衡的艺术

最近在做的项目进入到了测试阶段，首先本地测试性能水平还可以，于是很乐观的提交了alpha测试，但是很快测试人员反馈性能测试未过。从应用服务器所在硬件环境来说，两者都是差不多的性能，而且分别都是连接到独立mysql数据库。凭什么有如此测试结果呢？

从现象来看，排除本身业务逻辑算法的问题外，影响性能指标的因素不外乎数据库或大文件的I/O操作，CPU计算，网络传输耗时等三大关键点。首先CPU负载被排除在外，因为是后台应用服务，请求压力并不是很大，CPU资源非常充足。其次网络传输也被排除，因为站点本身的业务逻辑比较独立，并不需要访问外部的系统，所以最后的嫌疑就是I/O操作了，就是数据库的I/O操作。

分析到此之后，立马联系DBA分析原因，得知在alpha环境下使用的数据库服务器物理内存总共16G，启动了三个数据库实例，每个实例划分了4G的内存用作页面缓存，对于我开发的应用程序使用的数据库实例分到了4G的内存，但是由于这个数据库实例管理的是主库，数据量特别大，远远超过了分配的内存，而且由于有许多应用服务访问与我相同的主库，导致热点数据很分散，频繁的进行页面交换，不利于进行热点数据的缓存。

那现在回过头来看我们的本地环境链接的数据库为什么会没有这种情况呢，原来本地数据库环境内存虽然比alpha环境小，并且使用的实例却只有一个，当时测试的时间段，来自其他应用的请求也比较小，所以对于我们团队开发的应用所涉及到的热点数据能够很好的缓存起来，在大量的预热测试之后，数据可以直接从内存中访问，而节省了耗时的磁盘I/O操作。

根本原因大致如此。

 

在寻求答案过程，渐渐的发现，系统调优的工作其实就是一门如何在有关系统性能指标之间的达到平衡的艺术。

 

系统指标一般来讲CPU占用率，内存使用率，磁盘IO, 网络IO。

而评价系统性能一般可从两个数据：响应时间和吞吐量。

 

如果需要对系统调优的话，我一般会从三个维度来看：

 

第一种是横向维度，说白了就是增加服务器，分流请求使流量平衡，目的就是将把平衡机器站点的四大系统指标。

 

第二种是纵向维度，使内部系统在CPU，网络传输，I/O负载等指标找到平衡点，一个软件系统性能不佳，往往就是没有处理好这个四大指标之间的关系，对于CPU来说，显而易见的就是设置线程数量，多少是合适的，这个又取决于IO的时间和内核数，那最快捷的手法就是把将可能多的数据放到内存里去做计算，那么就需要在IO和内存之间寻找的一个好的平衡点。

 

第三种是时间维度，这个维度特别容易被忽略，因为往往出问题并不是出现白天哪几个高访问量的时刻，而是在半夜三更没有多少访问量的时间，因为许多团队或者项目习惯性将一些繁重的统计作业或者同步工作放在那几个点， 磁盘IO和CPU消耗特别大，而一旦有一些访问的请求，就经常都会遇到奇奇怪怪的问题。

 

平衡并不是对半开，不是1：1的问题，那是系统达到最佳状态的一个点，在平衡的过程中，更像能量守恒定律，在某一块指标降了，必然在另外一个地方涨了。