USE SysBench test Mysql and PostgreSQL - 2

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介:
 上一篇BLOG介绍了使用sysbench测试mysql和postgresql的simple场景.
也就是只有select的场景, 
本文将介绍包含复杂查询的场景, 包含如下SQL :
 INSERT INTO sbtest(k,c,pad) values(?,?,?)
 SELECT c from sbtest where id=$1
 UPDATE sbtest set k=k+? where id=$1
 SELECT DISTINCT c from sbtest where id between $1 and $2 order by c
 SELECT c from sbtest where id between $1 and $2 order by c
 SELECT SUM(K) from sbtest where id between $1 and $2
 SELECT c from sbtest where id between $1 and $2
 UPDATE sbtest set c=$1 where id=$2
 DELETE from sbtest where id=$1

但是需要先解决一个问题, 因为sysbench对pg的支持不太好, 在插入数据时使用的是sysbench产生的值, 而不是sequence.
会产生如下错误 :
[root@db-172-16-3-33 bin]# ./sysbench --max-requests=0 --max-time=60 --num-threads=16 --test=oltp --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=1999 --pgsql-user=postgres --pgsql-password=postgres --pgsql-db=postgres --oltp-test-mode=complex --oltp-reconnect-mode=session run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 16

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Threads started!
FATAL: query execution failed: 145040784
FATAL: database error, exiting...
Done.

日志 : 
2013-05-14 16:36:31.259 CST,"postgres","postgres",13938,"127.0.0.1:23937",5191f78f.3672,3,"INSERT",2013-05-14 16:36:31 CST,7/464628,
32112157,ERROR,23505,"duplicate key value violates unique constraint ""sbtest_pkey""","Key (id)=(5014) already exists.",,,,,"INSERT 
INTO sbtest values($1,0,' ','aaaaaaaaaaffffffffffrrrrrrrrrreeeeeeeeeeyyyyyyyyyy')",,"_bt_check_unique, nbtinsert.c:398",""

产生这个错误后sysbench会直接退出. 这就无法测试了.
所以需要修改一下sysbench的代码 :
vi sysbench-0.4.12/sysbench/tests/oltp/sb_oltp.c

找到
  /* Prepare the insert statement */
  snprintf(query, MAX_QUERY_LEN, "INSERT INTO %s values(?,0,' ',"
           "'aaaaaaaaaaffffffffffrrrrrrrrrreeeeeeeeeeyyyyyyyyyy')",
           args.table_name);

改成 : 
  /* Prepare the insert statement */
  if (args.auto_inc)
    snprintf(query, MAX_QUERY_LEN, "INSERT INTO %s(k,c,pad) values(0,' ',"
           "'aaaaaaaaaaffffffffffrrrrrrrrrreeeeeeeeeeyyyyyyyyyy')",
           args.table_name);
  else
    snprintf(query, MAX_QUERY_LEN, "INSERT INTO %s values(?,0,' ',"
           "'aaaaaaaaaaffffffffffrrrrrrrrrreeeeeeeeeeyyyyyyyyyy')",
           args.table_name);

然后重新编译即可.
如何编译参考 : 

接下来可以使用参数--oltp-auto-inc来控制选择是否使用序列.
[测试结果]
1. PostgreSQL
[root@db-172-16-3-33 bin]# ./sysbench --oltp-auto-inc=on --max-requests=0 --max-time=60 --num-threads=16 --test=oltp --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=1999 --pgsql-user=postgres --pgsql-password=postgres --pgsql-db=postgres --oltp-test-mode=complex --oltp-reconnect-mode=session run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 16

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Using auto_inc on the id column
Threads started!
Time limit exceeded, exiting...
(last message repeated 15 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            4328002
        write:                           1545715
        other:                           618286
        total:                           6492003
    transactions:                        309143 (5152.10 per sec.)
    deadlocks:                           0      (0.00 per sec.)
    read/write requests:                 5873717 (97889.81 per sec.)
    other operations:                    618286 (10304.19 per sec.)

Test execution summary:
    total time:                          60.0034s
    total number of events:              309143
    total time taken by event execution: 956.5899
    per-request statistics:
         min:                                  1.34ms
         avg:                                  3.09ms
         max:                                179.74ms
         approx.  95 percentile:               8.93ms

Threads fairness:
    events (avg/stddev):           19321.4375/325.75
    execution time (avg/stddev):   59.7869/0.02

2. MySQL
[root@db-172-16-3-33 bin]# ./sysbench --oltp-auto-inc=off --max-requests=0 --max-time=60 --num-threads=16 --test=oltp --db-driver=mysql --mysql-host=127.0.0.1 --mysql-port=3306 --mysql-user=root --mysql-password=root --mysql-db=test --oltp-test-mode=complex --oltp-reconnect-mode=session run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 16

Doing OLTP test.
Running mixed OLTP test
Using Special distribution (12 iterations,  1 pct of values are returned in 75 pct cases)
Using "BEGIN" for starting transactions
Not using auto_inc on the id column
Threads started!
Time limit exceeded, exiting...
(last message repeated 15 times)
Done.

OLTP test statistics:
    queries performed:
        read:                            1380960
        write:                           493088
        other:                           197237
        total:                           2071285
    transactions:                        98597  (1643.12 per sec.)
    deadlocks:                           43     (0.72 per sec.)
    read/write requests:                 1874048 (31231.08 per sec.)
    other operations:                    197237 (3286.96 per sec.)

Test execution summary:
    total time:                          60.0059s
    total number of events:              98597
    total time taken by event execution: 958.6545
    per-request statistics:
         min:                                  2.30ms
         avg:                                  9.72ms
         max:                                204.51ms
         approx.  95 percentile:              26.08ms

Threads fairness:
    events (avg/stddev):           6162.3125/43.34
    execution time (avg/stddev):   59.9159/0.00


[参考]
1. Install SysBench support MySQL and PostgreSQL
2. USE SysBench test Mysql and PostgreSQL - 1
相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
6天前
|
关系型数据库 MySQL 数据处理
Mysql 和 PostgreSQL 到底选啥?
Mysql 和 PostgreSQL 到底选啥?
16 0
|
6天前
|
关系型数据库 MySQL 分布式数据库
PolarDB MySQL版集群版本支持库表恢复功能的版本要求是什么?
【5月更文挑战第13天】PolarDB MySQL版集群版本支持库表恢复功能的版本要求是什么?
10 0
|
6天前
|
关系型数据库 MySQL 分布式数据库
如何将数据从MySQL迁移到PolarDB?
【5月更文挑战第13天】如何将数据从MySQL迁移到PolarDB?
23 0
|
6天前
|
SQL 关系型数据库 MySQL
【MySQL-1】理解关系型数据库&数据的数据模型
【MySQL-1】理解关系型数据库&数据的数据模型
|
6天前
|
关系型数据库 MySQL 测试技术
sysbench 对MySQL压测100分钟的命令
使用 `sysbench` 对 MySQL 数据库进行性能测试(压测)时,首先确保 `sysbench` 和 MySQL 数据库已经安装,并且你有一个测试数据库可以使用。下面是一个针对 MySQL 数据库进行压测的示例命令,测试时长为 100 分钟(6000 秒)。 在运行此命令之前,请确保以下内容: - 使用适当的数据库连接参数(主机、端口、用户名、密码、数据库名)。 - 根据你的需求调整测试参数(如并发数、线程数、事务数等)。 以下是一个示例命令,使用 `sysbench` 对 MySQL 数据库进行压测 100 分钟: ```shell sysbench --db-driver=m
|
6天前
|
DataWorks 关系型数据库 MySQL
DataWorks产品使用合集之在DataWorks中,如何通过PolarDB for MySQL来查看binlog日志
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
33 1
|
6天前
|
SQL 关系型数据库 MySQL
【MySQL】:探秘主流关系型数据库管理系统及SQL语言
【MySQL】:探秘主流关系型数据库管理系统及SQL语言
30 0
|
6天前
|
关系型数据库 MySQL 测试技术
【专栏】PostgreSQL数据库向MySQL迁移的过程、挑战及策略
【4月更文挑战第29天】本文探讨了PostgreSQL数据库向MySQL迁移的过程、挑战及策略。迁移步骤包括评估规划、数据导出与转换、创建MySQL数据库、数据导入。挑战包括数据类型不匹配、函数和语法差异、数据完整性和性能问题。应对策略涉及数据类型映射、代码调整、数据校验和性能优化。迁移后需进行数据验证、性能测试和业务验证,确保顺利过渡。在数字化时代,掌握数据库迁移技能对技术人员至关重要。
|
6天前
|
关系型数据库 MySQL 分布式数据库
PolarDB产品使用合集之PolarDB MySQL标准版中带有分区功能吗
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
|
6天前
|
关系型数据库 分布式数据库 数据库
VLDB顶会论文解读 | PolarDB MySQL高性能强一致集群核心技术详解
在VLDB2023会议上,阿里云瑶池数据库团队的论文介绍了PolarDB-SCC,这是一个创新的云原生数据库系统,确保了低延迟的全局强一致读取。PolarDB-SCC解决了传统主从架构中只读节点可能返回过期数据的问题,实现了在不影响性能的情况下提供强一致性。通过重新设计的主从信息同步机制、线性Lamport时间戳和细粒度修改跟踪,以及利用RDMA优化的日志传输,PolarDB-SCC已经在PolarDB中成功应用超过一年,成为业界首个无感知全局一致性读的云原生数据库解决方案。
66808 0