TPCC测试标准流程及结果
1. 测试流程标准
1.1. 硬件环境
- CPU：Intel(R) Xeon(R) Gold 6348H CPU @ 2.30GHz
测试机器的CPU是NUMA架构，因此可以使用numactl绑定CPU组
numactl --cpunodebind=0 --membind=0 pg_ctl
- 内存：754G
读取速度：16.4 GB/s
- 磁盘(SSD)
Cache read：10192 MB/s
Buffered disk read：3170 MB/s
- 网络
client ping server： rtt min/avg/max/mdev = 0.144/0.230/0.307/0.033 ms
server ping server：rtt min/avg/max/mdev = 0.171/0.228/0.256/0.023 ms
1.2. OS配置
- 解除资源限制
$ sudo vi /etc/security/limits.conf
# nofile超过1048576的话，一定要先将sysctl的fs.nr_open设置为更大的值，并生效后才能继续设置nofile.
* soft nofile 1024000
* hard nofile 1024000
* soft nproc unlimited
* hard nproc unlimited
* soft core unlimited
* hard core unlimited
* soft memlock unlimited
* hard memlock unlimited
- 设置块设备预读
首先找到数据库所在的磁盘的名字，再设置预读块大小
df -hT # 查看PG数据库所在的/data3的设备名是 /dev/nvme2n1p1
sudo blockdev --setra 16384 /dev/nvme2n1p1
1.3. 部署方法
本文测试的PostgreSQL和TeleDBX包括以下几种版本（TeleDBX基于PG10.23）：
- PG 10.23
- PG 11
- PGXC 1GTM 1DN （同机器）
- PGXC 1GTM 1DN 1CN （同机器）
- PGXC 1GTM 1DN （不同机器）
- PGXC 1GTM 1DN 1CN （GTM 机器1，DN和CN机器2）
- PGXC 1GTM 3DN 1CN (3个DN分别放在3台机器）
- PGXC 1GTM 3DN 3CN (DN均有主备，一台机器1CN 1DN)
1.4. 数据库参数配置
更改postgresql.conf的相关参数
- 重要参数
shared_buffers = 48GB(DN和PG)
shared_buffers = 6GB(CN)
max_connections = 5000
synchronous_commit = off
- 其他参数
superuser_reserved_connections = 3
tcp_keepalives_idle = 60
tcp_keepalives_interval = 10
tcp_keepalives_count = 10
max_prepared_transactions = 2000
work_mem = 128MB
maintenance_work_mem = 8GB
dynamic_shared_memory_type = posix
vacuum_cost_delay = 0
bgwriter_delay = 10ms
bgwriter_lru_maxpages = 1000
bgwriter_lru_multiplier = 10.0
effective_io_concurrency = 0
max_worker_processes = 128
max_parallel_workers_per_gather = 0
max_parallel_workers = 32
wal_level = minimal
wal_writer_delay = 10ms
checkpoint_timeout = 35min
max_wal_size = 128GB
min_wal_size = 32GB
checkpoint_completion_target = 0.1
max_wal_senders = 0
effective_cache_size = 400GB
log_autovacuum_min_duration = 0
autovacuum_max_workers = 16
autovacuum_freeze_max_age = 1200000000
autovacuum_multixact_freeze_max_age = 1400000000
autovacuum_vacuum_cost_delay = 0ms
vacuum_freeze_table_age = 1150000000
vacuum_multixact_freeze_table_age = 1150000000
cpu_tuple_cost=0.00018884145574257426
cpu_index_tuple_cost = 0.00433497085216479990
cpu_operator_cost = 0.00216748542608239995
seq_page_cost=0.014329
random_page_cost = 0.016
1.5. 测试数据-TPCC介绍
1.5.1. TPCC简介
TPC-C是业界常用的一套benchmark，由TPC委员会制定发布，用于评测数据库的联机交易处理（OLTP）能力。主要涉及9张表，包含五类业务事务模型（NewOrder–新订单的生成、Payment–订单付款、OrderStatus–最近订单查询、Delivery–配送、StockLevel–库存缺货状态分析）。
在TPC-C业务模式中，批发零件供应商（以下称为公司）在多个仓库及其相关的销售区域运营。TPC基准旨在随着公司的扩张和新仓库的创建而扩展。但是，随着基准的扩展，必须保持某些一致的要求。TPC-C模式中的每个仓库必须供应十个销售区，每个区为三千名客户提供服务。销售区的操作员可以随时选择公司订单输入系统提供的五种操作或交易之一。与事务本身一样，单个事务的频率是根据实际场景建模的。
最常见的交易包括输入一个新订单，平均由十个不同的项目组成。每个仓库都尝试维护公司目录中 100,000 件商品的库存，并从该库存中填写订单。但是，实际上，一个仓库可能无法拥有完成每个订单所需的所有零件。因此，TPCC要求所有订单的近百分之十必须由公司的另一个仓库供应。另一个频繁的交易包括记录从客户那里收到的付款。不太常见的是，操作员会请求先前下达的订单的状态，处理一批十个订单以进行交付，或者通过检查当地仓库的库存水平来查询系统是否存在潜在的供应短缺。然后，总共使用五种类型的事务对此业务活动进行建模。TPC-C 报告的性能指标衡量每分钟可以完全处理的订单数，以 tpm-C 表示。
1.5.2. TPCC事务介绍
TPC-C 系统需要处理的交易有以下五种：
- New-Order（占比45%）： 客户输入一笔新的订货交易
对于任意一个客户端，从固定的仓库随机选取 5-15 件商品，创建新订单。其中 1%的订单要由假想的用户操作失败而回滚。
特点：中量级、读写频繁、要求响应快。
- Payment（占比43%）：更新客户账户余额以反应其支付状况。
对于任意一个客户端，从固定的仓库随机选取一个辖区及其内用户，采用随机的金额支付一笔订单，并作相应历史纪录。
特点：轻量级，读写频繁，要求响应快。
- Delivery（占比4%）：发货(批处理交易)。
对于任意一个客户端，随机选取一个发货包，更新被处理订单的用户余额，并把该订单从新订单中删除。
特点：1-10 个批量，读写频率低，较宽松的响应时间
- Order-Status（占比4%）：查询客户最近交易的状态
对于任意一个客户端，从固定的仓库随机选取一个辖区及其内用户，读取其
最后一条订单，显示订单内每件商品的状态。
中量级，只读频率低，要求响应快。
- Stock-Level（占比4%）：查询仓库库存状况，以便能够及时补货。
特点：重量级，只读频率低，较宽松的响应时间。
1.5.3. 性能评价指标
- 流量指标(tpmC，Transactions Per Minute C)
描述了系统在执行 Payment，Order-Status，Delivery，Stock-level 这四种交易的同时，每分钟可以处理的New-Order交易的数量。流量指标值tpmC越大越好。要注意的是，在处理新订单的同时，系统还要按上图的要求处理其它4类事务请求。从图1 可以看出，新订单请求不可能超出全部事务请求的45％，因此，当一个系统的性能为1000tpmC时，它每分钟实际处理的请求数是2000多个。
- 性价比(Price/Performance，简称Price/tpmc)：
测试系统的整体价格与流量指标的比值，在获得相同的tpmC值的情况下，价格越低越好。
1.6. 测试工具
本文采用benchmarksql进行测试。在本文的测试中，统一采用1000 warehouse。首次测试的并发数（terminal）设置为48，并每次增加24，直到tpmC达到最大值。
- 下载benchmarkSQL
git clone benchmarksql.git
- 配置JDBC驱动
下载之后放入benchmarksql-lib目录下
# 本文下载的是JAVA 7 对应的驱动
wget jdbc.postgresql.org/download/postgresql-42.2.27.jre7.jar
cp postgresql-42.2.27.jre7.jar benchmarksql-5.0/lib
- 准备测试数据
本文选择1000warehouse
db=postgres
driver=org.postgresql.Driver
conn=jdbc:postgresql://10.129.180.92:15432/mydb
user=benchmarksql
password=password
warehouses=1000 //warehouses数量
loadWorkers=95 //灌数的并行load数
terminals=100
//To run specified transactions per terminal- runMins must equal zero
runTxnsPerTerminal=0
//To run for specified minutes- runTxnsPerTerminal must equal zero
runMins=20
//Number of total transactions per minute
limitTxnsPerMin=0
//Set to true to run in 4.x compatible mode. Set to false to use the
//entire configured database evenly.
terminalWarehouseFixed=true
//The following five values must add up to 100
//The default percentages of 45， 43， 4， 4 & 4 match the TPC-C spec
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4
// Directory name to create for collecting detailed result data.
// Comment this out to suppress.
//resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS
// osCollectorScript=./misc/os_collector_linux.py
// osCollectorInterval=1
// osCollectorSSHAddr=user@dbhost
// osCollectorDevices=net_eth0 blk_sda
- 准备测试数据
./runDatabaseBuild.sh props.pg
- 测试前，连接数据库预处理数据
pgsql#= analyze;
- 执行测试
./runBenchmark.sh props.pg
2. 测试过程监控
nmon命令
3. 测试调优
3.1. 系统指标定位
3.1.1. CPU
使用nmon命令查看CPU，主要关注idle%、sys%、usr%和iowait%。
- 若idle较高，则表示CPU较空闲，可增加客户端并发数。
- 若%iowait较高，表示硬盘存在I/O瓶颈，应该减少数据库IO操作的次数。
- 若%idle值如果持续低于10，表示系统的CPU处理能力相对较低，表明系统中最需要解决的资源是CPU（物理机暂时不存在此情况）。
3.1.2. 内存
dstat -t -m l
主要关注是否用到了swap。
3.1.3. IO
sudo iotop
3.1.4. 网络
nmon
3.1.5. 负载
理想情况下，每个 CPU 应该满负荷工作，且没有等待进程，此时，平均负载 = CPU 逻辑核数。
但是，在实际生产系统中，不建议系统满负荷运行。通用的经验法则是：平均负载 = 0.7 * CPU 逻辑核数。
- 当平均负载持续大于 0.7 * CPU 逻辑核数，就需要开始调查原因，防止系统恶化；
- 当平均负载持续大于 1.0 * CPU 逻辑核数，必须寻找解决办法，降低平均负载；
- 当平均负载持续大于 5.0 * CPU 逻辑核数，表明系统已出现严重问题，长时间未响应，
或者接近死机。
- 硬件环境
CPU核数、内存大小限制、CPU型号、存储SSD/磁盘、机器网络延迟ping，IO速度。
