浅谈系统性能调优思路

看了网上很多介绍linux性能调优的文章，感觉大部分都在讲一些实现方法、操作技巧，比如如何调整内核参数、如何优化cpu、内存、如何修改服务的某些参数等等。而调优思路上也有很多。比如马哥曾说调优的三个层次：一是硬件配置，二是内核调优，三是服务级别调优。高俊峰老师也在《高性能linux服务器构建实战》中提到过，当linux应用出现问题时，应从应用程序、操作系统、服务器硬件配置、网络环境等综合排查。二者的观点有共通之处。性能优化本身没有一个统一的方式方法，特别是针对不同的系统及应用来说。本文想重点讨论业务应用对性能优化的影响。

我认为的系统性能调优的思路应该先从业务应用入手，1.先分析你的业务是什么，有什么特点，比如并发量有多少、访问静态页面多还是提交的动态请求多、创建的小文件多还是大文件多、热数据多还是冷数据多等等；

2.再结合业务，确定系统架构，系统业务又围绕着可靠性、可用性、可扩展性来讲，比如你要怎样做负载均衡、你的底层raid要怎么设计、系统的读写策略、一致性的要求高不高、冗余策略如何设计、系统的可扩展性方案如何等等；

3.结合以上两点，选择用什么应用来跑业务。比如去选择Apache还是nginx（或者二者皆用）、varnish还是squid、redis还是memcached；而且应用上的参数调优也应该根据业务来定。

4.做了以上三点，最后落实到单个服务器上。实际上服务器的选型跟架构、业务、应用服务也有很大关系（当然你全部买最牛最贵的服务器也可以，但是高可靠性可用性可扩展性的提出，就是为了最大化提高性价比。Google的GFS就是搭在廉价的服务器上的）。比如一个Nginx静态页面请求服务器是不需要很高性能cpu的，而需要大量内存空间；apache动态请求服务器对cpu要求和IO要求都很高，而对内存的需求要结合后端数据库的大小和数据的冷热而定。

下面结合一些具体的业务应用实例来分析：

1.静态内容为主的web应用

比如一个博客网站、素材网站，特点是小文件居多，并且读操作频繁，写操作相对较少。从架构上讲，为了应付大并发请求，单一web服务器无法支撑大量客户端访问，此时需要多台web服务器组成负载均衡系统。又因业务是静态内容居多，于是需要大量缓存，所以在前端可以搭建cache服务器，将静态资源缓存到内存中直接进行读操作。由于又是读多写少，那么在做数据冗余时可以降低对数据一致性的要求，可以采取弱一直性策略或最终一致性策略。

综上，它的架构可以是前端负载均衡+cache缓存服务器，后端数据库服务器。负载均衡可以用DNS、LVS，业务比较单一的话其实负载均衡的策略不会太复杂，所以用Nginx、HAproxy也可以，并且Nginx还能支持很大的并发量。负载均衡服务器要选cpu强劲的，NUMA架构最合适不过，每个cpu之间可以并行处理请求，且对内存要求不高，避免交叉访问也不会对性能有影响。调优思路也主要集中在CPU上，比如怎么隔离中断、怎么划分子域、怎么规划cpu等。二在cache服务器这一层则需要高内存，当系统内存充足时，可以缓解磁盘随机读写压力；当内存用完时会开启虚拟内存的使用（所以规划的时候可以把虚拟内存划大点以应急），而虚拟内存的使用会引发I/O的增大，所以要对虚拟内存要做好监控。在内存调优上方法就比较多了，比如可以使用大页面（HugePages）、监控进程间的通信并调节共享内存和messages的参数。

2.以动态内容为主的web应用

这类应用的特点是频繁执行写操作，例如Java、PHP、Perl、CGI等，会导致cpu资源消耗严重。在架构上，如果做了负载均衡，那么要注意一个棘手的问题：数据的一致性。当多个请求被转发到不同的web服务器上并要访问同一个文件时，应该采取什么样的策略？如果用锁机制，那么访问速度会下降；如果用写时复制，速度会很快，但会消耗更多的内存；如果又刚好遇上了数据冗余多份，那么是否可以访问备份数据或者修改备份数据（因为这样做会大幅提升速度）？如果直接在备份数据上修改那么最终的同步策略又是怎样的？这些是在做负载均衡需要考虑的问题。

同样负载均衡的策略在这种情况下就不会那么简单了，应该选用LVS或者硬件负载均衡器。在分配请求或者说是分配进程到指定cpu上时，也有一个问题：请求平均了并不等于cpu使用率平均、进程平均了也不等于cpu/内存使用率平均。因为不是所有的请求或进程都消耗一样的cpu资源。应该针对业务去事先判断哪些请求消耗大，然后制定相应的转发策略；进程也是一样的，比如Java、php一类，事先性能测试时可得知其cpu使用率，根据cpu使用率划分cpu资源。当然也可以在业务跑起来的时候做一些相应的监控，得出进程的平均使用率再做进一步资源划分，我的上一篇文章有讲如何观察进程使用率及与cpu的绑定。

3.动静结合的web应用

了解了以上两个应用，动静结合就比较简单了：在负载均衡那层上将动态请求和静态请求分离，转发到相应策略的web上。

4.数据库应用

主要特点是消耗内存和磁盘I/O，而对cpu的消耗并不是很大。架构上，如果要做负载均衡的话，也要考虑一致性问题，选择什么样的一致性策略还是业务和需求决定的，我在1、2里面都有阐述，这里就不说了。业务量大的时候，可以加上一层缓存服务器，比如Memcached和redis一类。在数据库的设计上，如果业务是很多随机小文件，可以考虑将大表拆分，再通过索引进行关联处理，避免查询大表造成的性能问题。如果业务是连续大文件，其实不需要拆分，连续读写速度会较快。还有一种方法可以提升数据库性能：读写分离。根据读、写压力的需求，分别建立两波结构相同的数据库服务器，然后做定时同步数据，但这样速度会受影响。在硬件上，就要考虑raid的设计了。结合读写速度、冗余机制、数据冷热去决定用哪种raid，业务复杂也可以采用混合raid。

内容没有面面俱到，有不足和不对的地方，请雅正！