KingbaseES checkpoint_timeout参数对wal日志量的影响
前言
在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工具进行测试
[
](javascript:void(0)😉
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 <kingbase-bugs@kingbase.com.cn>.
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: <builtin: TPC-B (sort of)>
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
-----------------
t
(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)
[](javascript:void(0)😉
总结：
增加检查点间隔可以避免生成大量wal日志。而且检查点频繁发生会使脏块写入更频繁，这时候如果业务很繁忙，wal日志实际上也会发生大量磁盘写，综合分析，很容易造成磁盘IO繁忙，严重会影响业务正常运行，甚至造成一些数据库等待事件。所以我们需要根据业务系统类型，例如OLAP或OLTP，合理设置检查点时间。
另一方面，需要注意增加检查点时间间隔虽然对数据库性能有帮助，但是由于需要保留更多wal日志，所以当发生实例崩溃时，事务前滚回滚的时间也会加长，那么也将增加数据库恢复时间。
KINGBASE研究院
