《PostgreSQL 9.0性能调校》一一1.5 作为实践的性能优化

本节书摘来自异步社区出版社《PostgreSQL 9.0性能调校》一书中的第1章，第1.5节，作者： 【美】Gregory Smith，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.5　作为实践的性能优化

提高数据库性能与其他领域一样，有其专门的术语。下面是本书中要用到一些术语或短语。

瓶颈或限制因素：这两个术语常用于指明限制性能更进一步提升的当前的制约因素。
基准评测：运行一个测试以确定特定操作运行的速度。通常用来指明程序或者系统的瓶颈。
概要分析：监控在运行类似基准评测等复杂操作时，哪一部分程序使用了最多的资源。最典型的是指明瓶颈的位置，以及瓶颈被移除后是否有预期的效果。对一个数据库应用程序的概要分析通常是以vmstat和iostat等监控工具作为开始的。在代码级比较流行的概要分析工具有gprof、oprofile和dtrace。
在通常情况下，性能调优工作中比较令人关注的一个原则就是，用户无法指明应用程序在移除当前瓶颈之前会陷入哪一个瓶颈。假设某个系统运行的情况不能像用户预期的那样快，用户通常会去猜测当前的瓶颈在哪，或者下一个瓶颈又会是什么情况。这是很浪费时间的。用户最好能够进行性能测定，分析系统运行较慢的部分，用来确定原因以及指导相关的修改。

例如，用户已经知道应该提高的shared_buffers值，这个值用来调整缓冲数据库读和写时所使用的内存大小。这通常有些积极作用，但用户也有可能会遇到潜在的负面效果。需要指出哪一个应用程序会受到影响，这种变化是否会提高或降低性能，在服务器上运行的小设置能不能够进行预测。这是混沌理论的一种：在开始条件下即使是微小的变化，也将会引起非常不同的结果。例如，一个小小的度的变化，也会影响服务器数以百万计的决策。同样的，如果shared_buffers设置的值过小，会有部分参数不能像预期的那样良好运行，例如，在它们控制数据库检查点的情况下。

鉴于用户在绝大多数情况下无法预测将会发生的事，所以更倾向于用户进行深度的监控和变更控制。从应用程序到数据库服务器再到硬件，尽可能多地进行监控。这里引入一个有针对性的变化。尝试去量化具体的差异并且意识到某些用户所拒绝采用的修改不一定总是一直处于不积极状态之下。将瓶颈移到别的地方，用户就会发现在突然陷入下一个限制因素前，某些参数其实是无关紧要的。

在专注于PostgreSQL性能的邮件列表中，当用户没有做任何分析就推断其根本原因来证明他们的理论时，通常对此会有种通俗的表达：那就是“少说多做gprof”。虽然gprof可能不是每个性能问题要选择的工具，但是鉴于与其他一般的监控工具相比，它更多的是一种代码分析工具，用户在推断根本原因之前尽可能多的进行分析的做法是合理的。用户也需要进行推断来证实所期望的变化。

另一种在本书中反复和出现的原则就是：用户必须要把性能问题研究系统化。不能因为服务器是从名牌厂家购买的，就假设会运行得很快，基准评测是独立的组件。不要将数据库性能测试与应用程序级别的测试一同启动。首先运行那些可以与其他测试内容进行对比的综合的数据库性能测试。这样，当用户运行的应用程序不可避免地慢时，此时用户知道自身的硬件已经运行在预期的性能之内，并且数据库本身也良好运行。一旦用户的系统上线运行，需要做一些基本的不可能将系统拖垮的操作以查找出性能上的问题，例如，硬件速度的测试。

若用户部署的每台服务器都按照一些通用的方法进行测试的话，那么它会有更好的结构。接下来的章节将讲述测试相关内容。因为用户不是“唯器材是用”，这并不意味着用户可以跳过类似磁盘性能测试的这部分内容。用户在构建新的系统时应当经常进行此类工作——这是去获得最基本情况的惟一方法，而不管是否操作的这些行为在标准范围内抑或有些错误的操作。