pgbench使用_使用pgbench调整PostgreSQL

pgbench使用

当涉及到环境的性能调整时，通常首先要从数据库开始。 原因是大多数应用程序都非常依赖某种数据库。

不幸的是，数据库可能是最复杂的领域之一。 我之所以这样说，是因为适当地调整数据库服务通常涉及的调整远不止数据库服务本身。 它通常需要进行硬件，操作系统甚至应用程序的修改。

除了需要多种技能外，调优数据库的最大挑战之一是创建足够多的模拟数据库流量以增加数据库服务的压力。 这就是为什么今天的文章将探讨pgbench ，一种用于衡量PostgreSQL实例性能的基准测试工具。

PostgreSQL是一个非常流行的开源关系数据库。 PostgreSQL优点之一是，已经创建了许多工具来辅助PostgreSQL管理。 pgbench就是这样一种工具。

在探索pgbench ，我们还将使用它来衡量常见PostgreSQL可调参数的性能增益/损耗。

设置PostgreSQL实例

在使用pgbench调整数据库服务之前，我们必须首先建立该数据库服务。 以下步骤将概述如何在Ubuntu 16.04服务器上设置基本PostgreSQL实例。

使用

在Ubuntu系统上安装PostgreSQL非常容易。 只需执行apt-get命令即可完成大部分工作。

# apt-get install postgresql postgresql-contrib

上面的apt-get命令同时安装postgresql和postgresql-contrib软件包。 postgresql软件包将安装基本的PostgreSQL服务。

postgresql-contrib软件包将为PostgreSQL安装其他功能。 这些贡献尚未添加到官方程序包中，但通常会提供很多功能。

安装了软件包后，我们现在有了一个正在运行的PostgreSQL实例。 我们可以通过使用systemctl命令检查PostgreSQL状态来验证这一点。

# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2017-01-02 21:14:36 UTC; 7h ago
  Process: 16075 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 16075 (code=exited, status=0/SUCCESS)

Jan 02 21:14:36 ubuntu-xenial systemd[1]: Starting PostgreSQL RDBMS...
Jan 02 21:14:36 ubuntu-xenial systemd[1]: Started PostgreSQL RDBMS.

以上表明我们的实例启动没有任何问题。 现在，我们可以继续下一步，创建数据库。

建立资料库

当我们安装postgresql软件包时，此软件包包括创建名为postgres的用户。 该用户用作运行实例的所有者。 它还充当PostgreSQL服务的管理员用户。

为了创建数据库，我们需要登录到该用户，这可以通过执行su命令来完成。

# su - postgres

切换到postgres用户后，我们可以使用PostgreSQL客户端psql登录到正在运行的实例。

$ psql
psql (9.5.5)
Type "help" for help.

postgres=#

执行psql命令后，我们进入了PostgreSQL命令行环境。 从这里，我们可以发出SQL语句或使用特殊的客户端命令来执行操作。

例如，我们可以通过发出\list命令来列出当前数据库。

postgres-# \list
                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   
-----------+----------+----------+-------------+-------------+-----------------------
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(3 rows)

发出\list命令后，返回了三个数据库。 这些是在初始安装过程中设置的默认数据库。

对于今天的测试，我们将创建一个新的数据库。 让我们继续创建该数据库，并命名为example 。 我们可以通过发出以下SQL语句来做到这一点：

CREATE DATABASE example;

一旦执行，我们可以通过再次发出\list命令来验证数据库是否已经创建。

postgres=# \list
                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   
-----------+----------+----------+-------------+-------------+-----------------------
 example   | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(4 rows)

至此，我们现在有了一个名为example的空数据库。 至此，我们将需要返回bash shell来执行pgbench命令。 我们可以通过发出\q （退出）命令来做到这一点。

postgres-# \q

从PostgreSQL命令行环境注销后，我们可以开始使用pgbench来基准测试数据库实例的性能。

使用pgbench衡量性能

衡量数据库性能最困难的事情之一就是产生足够的负载。 一个流行的选择是简单地用测试事务轰炸目标应用程序的测试实例。 尽管这是一个有用的测试，可提供与应用程序相关的数据库性能，但有时由于应用程序瓶颈会限制数据库测试而会带来问题。

对于这种情况，可以使用pgbench工具。 使用pgbench ，您可以使用pgbench随附的示例数据库，也可以让pgbench针对应用程序数据库运行自定义查询。

在本文中，我们将使用pgbench附带的示例数据库。

设置

示例数据库的建立非常容易且相当快捷。 我们可以pgbench使用-i （初始化）选项执行pgbench来启动此过程。

$ pgbench -i -s 50 example
creating tables...
5000000 of 5000000 tuples (100%) done (elapsed 5.33 s, remaining 0.00 s)
vacuum...
set primary keys...
done.

在上面的命令中，我们使用-i选项和-s选项以及数据库名称（ example ）执行了pgbench 。

-i （初始化）选项将告诉pgbench初始化指定的数据库。 这意味着pgbench将在example数据库中创建以下表。

table                   # of rows
---------------------------------
pgbench_branches        1
pgbench_tellers         10
pgbench_accounts        100000
pgbench_history         0

默认情况下， pgbench将使用上面显示的行数创建上面的表。 这将创建一个简单的16MB数据库。

由于我们将使用pgbench来衡量性能变化，因此，一个16MB的小型数据库不足以对我们的实例施加压力。 这是-s （缩放）选项起作用的地方。

-s选项用于将输入每个表的行数相乘。 在上面的命令中，我们输入了50的“缩放比例”选项。 这告诉pgbench用默认大小的50倍创建一个数据库。

这意味着我们的pgbench_accounts表现在具有5,000,000条记录。 这也意味着我们的数据库大小现在为800MB （ 50 x 16MB ）。

为了验证我们的表已经成功创建，让我们继续运行psql客户端。

$ psql -d example
psql (9.5.5)
Type "help" for help.

example=#

在上面的命令中，我们使用了-d （数据库）标志来告诉psql不仅连接到PostgreSQL服务，而且还切换到示例数据库。

由于当前正在使用示例数据库，因此我们可以发出\dt命令以列出该数据库中可用的表。

example=# \dt
              List of relations
 Schema |       Name       | Type  |  Owner   
--------+------------------+-------+----------
 public | pgbench_accounts | table | postgres
 public | pgbench_branches | table | postgres
 public | pgbench_history  | table | postgres
 public | pgbench_tellers  | table | postgres
(4 rows)

从上表中，我们可以看到pgbench创建了四个预期表。 这意味着我们的数据库现在已填充，可以用来衡量我们的数据库实例的性能。

建立基线

在进行任何类型的性能调整时，最好首先建立基准性能。 此基准将用作衡量您执行的更改是提高还是降低了性能。

让我们继续调用pgbench为我们的“开箱即用”的PostgreSQL实例建立基线。

$ pgbench -c 10 -j 2 -t 10000 example
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 50
query mode: simple
number of clients: 10
number of threads: 2
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
latency average: 4.176 ms
tps = 2394.718707 (including connections establishing)
tps = 2394.874350 (excluding connections establishing)

调用pgbench ，我们在命令中添加了很多选项。 第一个是-c （客户端），用于定义要连接的客户端数量。 在此测试中，我使用10来告诉pgbench与10个客户端一起执行。

这意味着pgbench执行测试时，它将打开10个不同的会话。

下一个选项是-j （线程）标志。 该标志用于定义pgbench的工作进程数。 在上面的命令中，我指定了2的值。 这将告诉pgbench在基准测试期间启动两个工作进程。

使用的第三个选项是-t （事务），用于指定要执行的事务数。 在上面的命令中，我提供了10,000的值。 但是，这并不意味着将仅对我们的数据库服务执行10,000事务。 这意味着每个客户会话将执行10,000事务。

总而言之，基准测试运行是两个pgbench worker进程，它们模拟来自10客户端的10,000事务，总共100,000事务。

了解了这一点之后，让我们看一下第一个测试的结果。

$ pgbench -c 10 -j 2 -t 10000 example
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 50
query mode: simple
number of clients: 10
number of threads: 2
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
latency average: 4.176 ms
tps = 2394.718707 (including connections establishing)
tps = 2394.874350 (excluding connections establishing)

pgbench的输出有很多信息。 其中大部分描述了正在执行的测试方案。 我们最感兴趣的部分如下：

tps = 2394.718707 (including connections establishing)
tps = 2394.874350 (excluding connections establishing)

从这些结果来看，我们的基准似乎是2,394数据库事务。 让我们继续看看是否可以通过修改PostgreSQL中的简单配置参数来增加此数目。

添加更多缓存

任何调优PostgreSQL人都可以使用的参数之一是shared_buffers参数。 此参数用于指定PostgreSQL服务可用于缓存的内存量。 此缓存机制用于将表和索引的内容存储在内存中。

为了说明如何使用pgbench进行性能调整，我们将调整该值以测试性能的提高/降低。

默认情况下， shared_buffers值设置为128MB ，考虑到当今大多数服务器上的可用内存量，该值相当低。 通过查看/etc/postgresql/9.5/main/postgresql.conf文件的内容，我们可以自己看到此设置。 在此文件中，我们应该看到以下内容。

# - Memory -

shared_buffers = 128MB                  # min 128kB
                                        # (change requires restart)

让我们继续，将此值切换为256MB ，有效地将可用缓存空间增加一倍。

# - Memory -

shared_buffers = 256MB                  # min 128kB
                                        # (change requires restart)

完成后，我们将需要重新启动PostgreSQL服务。 我们可以通过使用带有restart选项的systemctl命令来执行此操作。

# systemctl restart postgresql

服务完全启动并运行后，我们可以再次使用pgbench来衡量我们的性能。

$ pgbench -c 10 -j 2 -t 10000 example
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 50
query mode: simple
number of clients: 10
number of threads: 2
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
latency average: 3.921 ms
tps = 2550.313477 (including connections establishing)
tps = 2550.480149 (excluding connections establishing)

在我们之前的基准测试中，我们能够达到每秒2,394事务的速率。 在最后一次运行中，更新了shared_buffers参数之后，我们每秒能够实现2,550事务，增加了156 。 尽管这不是一个坏的开始，但我们仍然可以走得更远。

尽管shared_buffers参数的shared_buffers可能为128MB ，但此参数的建议值为系统内存的四分之一。 我们的测试系统具有2GB的系统内存，我们可以使用free命令验证该值。

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           2000          54         109         548        1836        1223
Swap:             0           0           0

在上面的输出中，我们可以看到total列在内存行上显示了2000MB的值。 此列显示系统可用的总物理内存。 我们还可以在available列中看到1223MB显示可用。 这意味着我们最多有1.2 GB的可用内存可用于调整目的。

如果我们将shared_buffers参数更改为四分之一系统内存的建议值，则需要将其更改为512MB 。 让我们继续进行更改，然后重新运行pgbench测试。

# - Memory -

shared_buffers = 512MB                  # min 128kB
                                        # (change requires restart)

通过/etc/postgresql/9.5/main/postgresql.conf的shared_buffers值更新，我们可以继续并重新启动PostgreSQL服务。

# systemctl restart postgresql

重新启动后，让我们重新运行测试。

$ pgbench -c 10 -j 2 -t 10000 example
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 50
query mode: simple
number of clients: 10
number of threads: 2
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
latency average: 3.756 ms
tps = 2662.750932 (including connections establishing)
tps = 2663.066421 (excluding connections establishing)

这次，我们的系统能够达到每秒2,662笔交易，每秒增加112笔交易。 由于我们的每秒两次交易至少增加了100次，因此让我们更进一步，看看将此值更改为1GB会发生什么。

# - Memory -

shared_buffers = 1024MB                 # min 128kB
                                        # (change requires restart)

更新值后，我们将需要再次重新启动PostgreSQL服务。

# systemctl restart postgresql

服务重新启动后，我们现在可以重新运行测试。

$ pgbench -c 10 -j 2 -t 10000 example
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 50
query mode: simple
number of clients: 10
number of threads: 2
number of transactions per client: 10000
number of transactions actually processed: 100000/100000
latency average: 3.744 ms
tps = 2670.791865 (including connections establishing)
tps = 2671.079076 (excluding connections establishing)

这次，我们的每秒交易量从2,662增至2,671 ，每秒增加了9笔交易。 在这种情况下，我们的收益正在下降。

尽管在许多环境中增加shared_buffers值超出四分之一准则是可行的，但是这样做不会为此测试数据库返回相同的结果。

摘要

根据我们的测试结果，我们可以看到，在我们的测试系统上，将shared_buffers的值从128MB更改为512MB使性能每秒提高268事务。 根据我们的基准结果，性能提高了10％ 。

我们使用pgbench的示例数据库在一个基本的PostgreSQL实例上完成了所有这些工作。 这意味着，我们不必加载我们的应用程序即可获得有关PostgreSQL性能的基线指标。

尽管我们可以通过在PostgreSQL中修改shared_buffers参数来提高吞吐量，但还有许多可用的调整参数。 对于希望调优PostgreSQL实例的任何人，我强烈建议您查看PostgreSQLWiki 。

翻译自: https://www.javacodegeeks.com/2017/01/tuning-postgresql-pgbench.html

pgbench使用