人大金仓 DBA 金仓数据库KingbaseES checkpoint

前言

在KingbaseESV8R6数据库中，必须先将更改写入WAL日志(老版本称为 xlog)，然后才能将这些更改从内存shared_buffer 写入到磁盘。

前两天有个同事遇到一个问题，wal日志每天生成120GB，于是我们检查了参数checkpoint_timeout参数是默认的5min。然而这个参数应该根据实际的业务类型进行调整，建议调整为30-60分钟。

增加检查点之间的距离会导致WAL日志减少，相当于增加checkpoint_timeout参数，就相对减少wal日志量生成。因为当开启了full_page_writes参数(默认开启)，每次检查点后的第一次写入wal日志必然发生一次全页写。所以这就大大增加了wal日志量。

检查点相关参数：checkpoint_timeout自动 WAL 检查点之间的最长时间，以秒计。合理的范围在 30 秒到 1 天之间。默认是 5 分钟( 5min )。增加这个参数的值会增加崩溃恢复所需的时间。这个参数只能在 kingbase.conf 文件中或在服务器命令行上设置。

checkpoint_completion_target指定检查点完成的目标，作为检查点之间总时间的一部分。默认是 0.5。这个参数只能在 kingbase.conf 文件中或在服务器命令行上设置。

max_wal_size在检查点之间允许重做日志增长到的最大尺寸。这是一个软限制，在特殊的情况下重做文件尺寸可能会超过max_wal_size。如果指定值时没有单位，则以兆字节为单位。默认为 1 GB。增加这个参数可能导致崩溃恢复所需的时间。这个参数只能在kingbase.conf或者服务器命令行中设置。

测试wal日志生成量对比

这里使用kbbench工具进行测试

kbbench参数说明：

[kingbase2@localhost ~]$ kbbench --help

kbbench is a benchmarking tool for Kingbase.

Usage:

kbbench [OPTION]... [DBNAME]

Initialization options:

-i, --initialize invokes initialization mode

-I, --init-steps=[dtgvpf]+ (default "dtgvp")

run selected initialization steps

-F, --fillfactor=NUM set fill factor

-n, --no-vacuum do not run VACUUM during initialization

-q, --quiet quiet logging (one message each 5 seconds)

-s, --scale=NUM scaling factor

--foreign-keys create foreign key constraints between tables

--index-tablespace=TABLESPACE

create indexes in the specified tablespace

--tablespace=TABLESPACE create tables in the specified tablespace

--unlogged-tables create tables as unlogged tables

Options to select what to run:

-b, --builtin=NAME[@W] add builtin script NAME weighted at W (default: 1)

(use "-b list" to list available scripts)

-f, --file=FILENAME[@W] add script FILENAME weighted at W (default: 1)

-N, --skip-some-updates skip updates of kbbench_tellers and kbbench_branches

(same as "-b simple-update")

-S, --select-only perform SELECT-only transactions

(same as "-b select-only")

Benchmarking options:

-c, --client=NUM number of concurrent database clients (default: 1)

-C, --connect establish new connection for each transaction

-D, --define=VARNAME=VALUE

define variable for use by custom script

-j, --jobs=NUM number of threads (default: 1)

-l, --log write transaction times to log file

-L, --latency-limit=NUM count transactions lasting more than NUM ms as late

-M, --protocol=simple|extended|prepared

protocol for submitting queries (default: simple)

-n, --no-vacuum do not run VACUUM before tests

-P, --progress=NUM show thread progress report every NUM seconds

-r, --report-latencies report average latency per command

-R, --rate=NUM target rate in transactions per second

-s, --scale=NUM report this scale factor in output

-t, --transactions=NUM number of transactions each client runs (default: 10)

-T, --time=NUM duration of benchmark test in seconds

-v, --vacuum-all vacuum all four standard tables before tests

--aggregate-interval=NUM aggregate data over NUM seconds

--log-prefix=PREFIX prefix for transaction time log file

(default: "kbbench_log")

--progress-timestamp use Unix epoch timestamps for progress

--random-seed=SEED set random seed ("time", "rand", integer)

--sampling-rate=NUM fraction of transactions to log (e.g., 0.01 for 1%)

Common options:

-d, --debug print debugging output

-h, --host=HOSTNAME database server host or socket directory

-p, --port=PORT database server port number

-U, --username=USERNAME connect as specified database user

-V, --version output version information, then exit

-?, --help show this help, then exit

Report bugs to .

1)创建测试数据库kbbench ：

createdb -p 2920 -U SYSTEM kbbench ;

2)初始化测试数据：

kbbench -i -s 10 -p 2920 -U SYSTEM kbbench

重点：主要用到两个参数，‐i：初始化模式，‐s 插入的倍数，默认是1，即插入100000条，这里设置10，即插入100万条记录

[kingbase2@localhost sys_wal]$ kbbench -i -s 10 -p 2920 -U SYSTEM kbbench

dropping old tables...

creating tables...

generating data...

100000 of 1000000 tuples (10%) done (elapsed 0.07 s, remaining 0.63 s)

200000 of 1000000 tuples (20%) done (elapsed 0.18 s, remaining 0.70 s)

300000 of 1000000 tuples (30%) done (elapsed 0.29 s, remaining 0.67 s)

400000 of 1000000 tuples (40%) done (elapsed 0.39 s, remaining 0.59 s)

500000 of 1000000 tuples (50%) done (elapsed 0.49 s, remaining 0.49 s)

600000 of 1000000 tuples (60%) done (elapsed 0.60 s, remaining 0.40 s)

700000 of 1000000 tuples (70%) done (elapsed 0.71 s, remaining 0.30 s)

800000 of 1000000 tuples (80%) done (elapsed 0.82 s, remaining 0.21 s)

900000 of 1000000 tuples (90%) done (elapsed 1.01 s, remaining 0.11 s)

1000000 of 1000000 tuples (100%) done (elapsed 1.12 s, remaining 0.00 s)

vacuuming...

creating primary keys...

done.

开始测试:

kbbench -c 4 -j 4 -T 100 -r -p 2920 -U SYSTEM kbbench;

-c 总连接数，创建多少个连接到数据库，一般数据库接受连接数默认为100，其中需要预留

3个左右的连接。

-j 进程数量，每个进程创建n个连接，那么就存在如下关系：－c ＝－j ＊n，建议为服务

器的CPU核数。

-T 测试持续时间，指定了-T就不能指定-t,每个连接执行的事物数量。即，要么指定测试多

长时间，要么指定测试多少个事物。

-r 显示每一步操作的平均时间。

-f 指定测试脚本，不指定则使用默认脚本。这里使用的默认脚本。

[kingbase2@localhost ~]$ kbbench -c 4 -j 4 -t100 -r -p 2920 -U SYSTEM kbbench;

starting vacuum...end.

transaction type:

scaling factor: 1

query mode: simple

number of clients: 4

number of threads: 4

duration: 100 s

number of transactions actually processed: 104125

latency average = 3.842 ms

tps = 1041.164501 (including connections establishing)

tps = 1041.374809 (excluding connections establishing)

statement latencies in milliseconds:

0.001 \set aid random(1, 100000 * :scale)

0.000 \set bid random(1, 1 * :scale)

0.000 \set tid random(1, 10 * :scale)

0.000 \set delta random(-5000, 5000)

0.241 BEGIN;

0.173 UPDATE kbbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;

0.406 SELECT abalance FROM kbbench_accounts WHERE aid = :aid;

0.867 UPDATE kbbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;

1.453 UPDATE kbbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;

0.160 INSERT INTO kbbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);

0.538 END;

kbbench=# select pg_size_pretty(sum(size)) from pg_ls_waldir();

pg_size_pretty

----------------

160 MB

(1 row)

调整检查点时间为30s，再次进行测试

alter system set checkpoint_timeout='1min'

TEST=# select sys_reload_conf();

sys_reload_conf

-----------------

(1 row)

TEST=# show checkpoint_timeout ;

checkpoint_timeout

--------------------

1min

(1 row)

TEST=# drop database kbbench;

DROP DATABASE

再次执行一次以上的测试步骤

createdb -p 2920 -U SYSTEM kbbench ;

kbbench -i -s 10 -p 2920 -U SYSTEM kbbench

kbbench -c 4 -j 4 -T 100 -r -p 2920 -U SYSTEM kbbench;

wal日志量增长3倍左右，因为检查点发生的更频繁，导致检查点发生后第一次写入的wal日志是full page，也就是写入了8K，无形中增加了wal日志量。

TEST=# select pg_size_pretty(sum(size)) from pg_ls_waldir();

pg_size_pretty

----------------

462 MB

(1 row)

总结：

增加检查点间隔可以避免生成大量wal日志。而且检查点频繁发生会使脏块写入更频繁，这时候如果业务很繁忙，wal日志实际上也会发生大量磁盘写，综合分析，很容易造成磁盘IO繁忙，严重会影响业务正常运行，甚至造成一些数据库等待事件。所以我们需要根据业务系统类型，例如OLAP或OLTP，合理设置检查点时间。另一方面，需要注意增加检查点时间间隔虽然对数据库性能有帮助，但是由于需要保留更多wal日志，所以当发生实例崩溃时，事务前滚回滚的时间也会加长，那么也将增加数据库恢复时间。更多信息，参见https://help.kingbase.com.cn/v8/index.html

金钥匙

人大金仓 DBA 金仓数据库KingbaseES checkpoint

大数据数据库开发数据库管理员【数据库原理 • 六】数据库备份与恢复

运维 sql dba 达梦数据库参数调整篇

发表评论取消回复

金钥匙

人大金仓 DBA 金仓数据库KingbaseES checkpoint

大数据 数据库开发 数据库管理员 【数据库原理 • 六】数据库备份与恢复

运维 sql dba 达梦数据库参数调整篇

相关文章

发表评论取消回复

大数据数据库开发数据库管理员【数据库原理 • 六】数据库备份与恢复