目录
环境
Postgresql FDW 与 Oracle 安装在同一台机器上。
客户端为JDBC,运行在remote PC(Dell Inspiron 3576,网卡:rtl810x/8139)上。
硬件配置:
CPU i7-4790
内存 32G
固态硬盘+机械硬盘
建表
oracle建表
create tablespace ckspace
datafile '/data2/oradata/tbs_ck.dbf'
size 20480M
autoextend on;
alter user test quota unlimited on ckspace;
create table cktest(
id int,
col1 int,
col2 int,
col3 int,
col4 int,
col5 int,
col6 int,
col7 int,
col8 int,
col9 int,
col10 int,
col11 varchar(30),
col12 varchar(30),
col13 varchar(30),
col14 varchar(30),
col15 varchar(30),
col16 varchar(30),
col17 varchar(30),
col18 varchar(30),
col19 varchar(30),
col20 varchar(30),
col21 varchar(30)
)tablespace ckspace;
先建立表空间,将数据文件固定在固态硬盘,将新表绑定到该空间。
PG建立外部表
create extension oracle_fdw;
create server oracledb foreign data wrapper oracle_fdw options(dbserver '//127.0.0.1:1521/ORCL');
create user mapping for postgres server oracledb options (user 'test',password 'test');
create foreign table "cktest"(
"id" int,
"col1" int,
"col2" int,
"col3" int,
"col4" int,
"col5" int,
"col6" int,
"col7" int,
"col8" int,
"col9" int,
"col10" int,
"col11" varchar(30),
"col12" varchar(30),
"col13" varchar(30),
"col14" varchar(30),
"col15" varchar(30),
"col16" varchar(30),
"col17" varchar(30),
"col18" varchar(30),
"col19" varchar(30),
"col20" varchar(30),
"col21" varchar(30)
) server oracledb options(schema 'TEST', table 'CKTEST');
外部表关联到之前ORACLE建立的新表cktest.
在后面的多线程测试当中,会照此依次建立多张表
单线程测试
数据描述
id, 第几行
col1 ~ col10 , 都是随机数
col11~col21, 随机长度的随机字符串
设定随机种子,保证每次测试的数据完全一样。
1. batchsize 设定为1000, 一次commit 1000行数据
2. 总行数10000000,一千万行。
batchsize | 1000 |
rows | 10000000(1000W) |
total data bytes | 2089929045(2G) |
postgresql.conf修改:
max_connections = 256
shared_buffers = 1024MB
wal_buffers = 64kB
测试结果
ORACLE | 第一次 | 第二次 |
写入速度 | 7.6MB/s | 7.6MB/s |
耗时 | 262秒 | 260秒 |
PG FDW | 第一次 | 第二次 | 第三次 |
写入速度 | 1.53 MB/s | 1.52MB/s | 1.51MB/s |
耗时 | 1301秒 | 1305秒 | 1317秒 |
ORACLE写入性能是 PG FDW的 5 倍。
资源消耗:
写入ORACLE,CPU占用率不高,oracle 20%左右。
写入PG FDW
CPU占用率明显升高,postmaster 60%, oracle 30%,但是不清楚是否造成瓶颈
网络localhost 很大,15Mbytes每秒,不过Localhost主要依赖CPU,跟实际网络不同。
调整参数测试
postgresql.conf修改
其中checkpoint_segments在9.5以后被弃用,用max_wal_size来设定。值大一点降低check point频率。
shared_buffers = 3GB 默认128MB 数据库服务器将使用的共享内存缓冲区大小,该缓冲区为所有连接共用。从磁盘读入的数据(主要包括表和索引)都缓存在这里。
work_mem = 16MB # min 64kB 默认4MB
maintenance_work_mem = 256MB # min 1MB 默认64MB
wal_buffers = 4MB
checkpoint_timeout = 10min # range 30s-1d 默认5min
max_wal_size = 2GB 默认1GB # max_wal_size = (3 * checkpoint_segments) * 16MB, 2G = segments 64
checkpoint_completion_target = 0.9 默认0.5
effective_cache_size = 3GB
fsync = off # flush data to disk for crash safety
synchronous_commit = off # synchronization level;
调整后测试结果
与调整前一致,这些参数对FDW性能不是瓶颈。
PG FDW | 第一次 | 第二次 |
写入速度 | 1.53 MB/s | 1.53 MB/s |
耗时 | 1300秒 | 1297秒 |
多线程测试
数据简述
多线程写入,每个线程写入一张表,多线程对应多张表,同时写入。
写入速率为 总数据量 / 总时间得到。
测试结果
综合之前单线程的结果
写入速率 | 单线程 | 2线程 | 4线程 |
PG FDW | 1.53 MB/s | 2.9 MB/s | 4.92 MB/s |
ORACLE | 7.6 MB/s | 9.17 MB/s | 9.4MB/s |
服务端会同时开启4个postmaster的子进程来执行insert操作。PG FDW在多线程表现,接近线性增长,但是在4线程写入的时候,CPU占用非常高。
直接写入ORACLE在2线程到9MB/s以后提升不明显,有可能是到了局域网络的瓶颈。
除网络外,其他的资源占用也并不多。
更换JDBC客户端(神舟 z7m-kp7s,网卡rtl8168/8111/8112)设备再测,网络瓶颈少了很多,两者差距更明显。
单线程 | 2线程 | 4线程 | |
PG FDW | 1.59 MB/S | 3.92 MB/S | 5.08 MB/S |
ORACLE | 18.94 MB/S | 34.8 MB/S | 43.2 MB/S |
小结
从目前测试结果来看,默认的postgresql.conf参数并不是FDW性能的瓶颈。
多线程写入,服务器多进程写入,性能提升接近线性,瓶颈应该就在这个写入的进程中了。
下一步将研究oracle_FDW代码, 理理清楚,找到瓶颈所在。