编译工具脚本开源在 https://github.com/bash99/pgobuild_percona_server 选 percona server 这个版本的原因是,完善的兼容性和优秀的特性(比如只有 mysql enterprise 才有的 pool of threads)
采用Profile-Guided Optimization 方式编译优化,用 sysbench 来模拟 workload.
| TPS | 5.6 | 5.6_PGO | 提升比 | 5.7 | 5.7_PGO | 提升比 |8.0 | 8.0_PGO | 提升比 |
| ----------| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| point_select| 70106.22 |92630.52 |32.13% |70180.87 |100511.44 |43.22% |61668.86 |94908.89 |53.90% |
| read_only |1969.35 |2537.66 |28.86% |2404.53 |3229.28 |34.30% |2846.61 |3709.64 |30.32% |
| read_write |1387.48 |1780.91 |28.36% |1596.53 |2246.4 |40.71% |1417.5 |1743.1 |22.97% |
(V2EX 的 markdown 语法还不支持表格吗?)
硬件: 8 核 16G 内存 100G SSD 的虚拟机, 4.8G 的 innodb memory pool,数据集 7.7G (sysbench oltp 2M table size, 16 tables), 16 线程访问. 虽然是以 sysbench 模拟 workload,但是对于tpcc 风格的负载,也有 7%的提升(scale = 10 , tables = 10)。 虽然以 innodb 作为引擎模拟,但是对于 rocksdb 的引擎也有 14~24%的提升。
需要 Centos 7 系统,保证 4G 内存(更低没测过,测试数据集 7.7G ,因此再小就是 IO-Bound 应用了) ,当前目录还有 15G 空间( ssd,否则被 IO 限制的情况下,针对 cpu 性能的编译优化毫无意义),并且有 sudo 权限(需要安装相关系统依赖包)
## 下载已编译的版本及官方二进制版
## 12M
wget -c https://dl.ximen.bid/mini_percona-server-5.6.44-86.0-pgo-linux-x86_64.tar.xz
## 113M
wget -c https://www.percona.com/downloads/Percona-Server-5.6/Percona-Server-5.6.44-86.0/binary/tarball/Percona-Server-5.6.44-rel86.0-Linux.x86_64.ssl101.tar.gz
## 314M !!
wget -c https://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.44-linux-glibc2.12-x86_64.tar.gz
## 下载 sysbench 静态编译版本,可以略过自行编译,请设置好 SYSBENCH_BASE
export SYSBENCH_BASE=`pwd`/sysbench_bin
mkdir -p $SYSBENCH_BASE
curl -L -q https://dl.ximen.bid/sysbench-1.17.static.tar.xz | tar -Jxf - -C $SYSBENCH_BASE --strip-components=1
## 下载脚本工具
git clone https://github.com/bash99/pgobuild_percona_server.git pspgo-utils
## 安装依赖包
sudo pspgo-utils/prepare/install-misc.sh
## 设置系统 limits
# sudo pspgo-utils/prepare/init_syslimit.sh
## 设置版本号,mysql 安装路径
export MYSQL_VER=5.6
export MYSQL_BASE="`pwd`/local/ps-$MYSQL_VER"
## 测试官方 sysbench 结果,分别是 point select / oltp readonly / oltp readwrite
rm -rf "$MYSQL_BASE"
bash `pwd`/pspgo-utils/build-normal/test_binary.sh mysql-5.6.44-linux-glibc2.12-x86_64.tar.gz "$MYSQL_BASE" $MYSQL_VER
grep transactions /tmp/sb_test_bin_result.txt > mysql_offical_result.txt
## 测试官方 sysbench 结果,分别是 point select / oltp readonly / oltp readwrite
rm -rf "$MYSQL_BASE"
bash `pwd`/pspgo-utils/build-normal/test_binary.sh mini_percona-server-5.6.44-86.0-pgo-linux-x86_64.tar.xz "$MYSQL_BASE" $MYSQL_VER
grep transactions /tmp/sb_test_bin_result.txt > pgo_result.txt
## 测试官方 sysbench 结果,分别是 point select / oltp readonly / oltp readwrite
rm -rf "$MYSQL_BASE"
bash pspgo-utils/build-normal/test_binary.sh Percona-Server-5.6.44-rel86.0-Linux.x86_64.ssl101.tar.gz "$MYSQL_BASE" $MYSQL_VER
grep transactions /tmp/sb_test_bin_result.txt > normal_result.txt
grep trans mysql_offical_result.txt normal_result.txt pgo_result.txt
在一台 aws 的 C3large 机器上执行的结果( 2 核 3.75G ,两个 16G 的 ssd 盘做 raid0 ),PGO 编译的 binary 是在 8 核 16G 的虚机上产生的。
offical_result.txt: transactions: 944190 (18880.84 per sec.)
offical_result.txt: transactions: 85992 (537.38 per sec.)
offical_result.txt: transactions: 61397 (383.64 per sec.)
percona_result.txt: transactions: 905104 (18099.37 per sec.)
percona_result.txt: transactions: 84038 (525.16 per sec.)
percona_result.txt: transactions: 61317 (383.12 per sec.)
pgo_result.txt: transactions: 1330627 (26608.29 per sec.)
pgo_result.txt: transactions: 114073 (712.86 per sec.)
pgo_result.txt: transactions: 80200 (501.13 per sec.)
MariaDB 的 Enterprise 版本就曾经称是 PGO 编译的. PGO 用于数据库是完全可行的,这个项目就是受到该文的启发。
gcc 6 + 5.7.19 的编译版本在内部近 100 台实例上运行一年半左右,无 crash 记录,工作时间系统平均负载第一周下降 14%左右。
1
linora 2019-08-22 11:11:41 +08:00
支持一下
|
2
lambdaq 2019-08-22 11:22:42 +08:00
说得不错。我选择 pg
btw 这个 PGO 可以用在 CPython 上不? |
4
gz911122 2019-08-22 14:34:46 +08:00
干货支持一下
|
5
dazhangpan 2019-08-26 18:03:27 +08:00
PGO 的优化效果只能用在固定的 workload 上吧?
|
6
bash99 OP @dazhangpan 如果用来测试的 workload 足够通用,比如这个 pgo 之后对类 tpcc 的负载也有提升( https://github.com/Percona-Lab/tpcc-mysql ),当然你可以自行测试。
|