性能优化¶
参数优化分类¶
源端读取文本文件优化¶
-rm(readmode): 读文件模式：MMAP 内存映射模式、PREAD 批量读取模式、AIO 异步IO模式。默认为：MMAP。
-rt(readthread): 源端为文本时读文件线程数，默认为 1。
-b(ssplitsize): 文件分割大小，单位为M，默认为50。
-k(sthreadcount): 获取源数据线程数，默认为4。
源端读取数据库优化¶
-p(sdbparall): 源库导出表的并行模式:off(关闭并行)、package(按包并行)、partition(按分区并行)、node(按node并行)。默认为partition。
本参数只有和参数 -t(sdbtab)配合使用时才有效。如果从源端数据库取出整表数据，可以对表的数据进行不同程度的分割。例如：如果源端表建在xCluster上，可以设置sdbparall=node，表示按照节点分割；如果源端表是ksotre表，可以设置sdbparall= package，表示按照包分割；如果源端表包含分区，可以设置sdbparall= partition，表示按照分区分割。
-b(ssplitsize): 并行分割大小。只有当-p为package时有效，表示package数，默认为50。
-g(sfetchsize): 源库预取行数，即每次从后台获取的数据行数，默认为 1000。
-k (sthreadcount): 获取源数据线程数，默认为4。
Buffer池优化¶
-N(commitcount): 提交行数，默认为10000。
-Z(commitsize): 提交大小，单位M， 默认30。
-Q(committime): 提交时间，单位s，默认为 -1 表示无限大。
-B(dbufcount): BUF数量，默认为4。
-SI(schedulerinterval): 调度器轮询查询时间间隔，单位ms，默认100
目的端数据库优化¶
-K(dthreadcount): 导入到目的端的线程数，也即session池中session个数，默认为4。
调优方向¶
datamigrate 性能比较理想的情况是：当源端获取到数据时，可以得到空闲的BUF，同时一直有ready的BUF供目的端导入。即源端与目的端均处于忙的状态。当源端或目的端空闲时，有可能导致datamigrate性能差。可以通过后台日志或者第三方工具帮助分析。
1)后台日志分析(目的端为数据库)
datamigrate 运行的同时打开后台日志，可以看到后台导入log。
如果后台没有一直导入，而是需要等一段时间才导入，此时有可能出现了目的端空闲。如果后台一直导入，此时datamigrate性能仍然很差，有可能是后台导入比较耗时，占用所有可用的BUF，源端获取到数据时，需要等空闲BUF，即源端出现了空闲。
2)第三方工具：pidstat(目的端为文本)
pidstat 可以看进程CPU占用率及IO 写磁盘速率。可以设置每秒刷新一下。
如果刷新多次IO才有数据，说明目的端空闲了，在等ready BUF。如果每次刷新IO都有数据，可能写文件比较耗时，有可能占用了所有的BUF导致源端空闲。
源端空闲时¶
后台需要尽快释放BUF，BUF也提升自己产生空闲BUF的能力。
目的端优化参数参考：调整-K 参数值。
BUF优化参数可参考：减小-N 参数值，减小-Z 参数值，这样可以减少后台每次插入的行数，加快后台释放出BUF的速度。增大-B参数值，该参数值可以设置的比-K参数值大一些，这样可以在后台占用-K个BUF的时候，仍然有空闲BUF供源端加载数据。
源端优化参数可参考：源端为数据库时，增大-g 参数值；源端为文本时，增大-rt 参数值，调整-b参数值。
目的端空闲时¶
源端需要调整参数加快获取数据的速度，BUF需要调整参数尽快产生ready BUF供目的端导入。
源端优化参数可参考：增大-k参数值。源端为数据库时，增大-g 参数值；源端为文本时，增大-rt 参数值，调整-b参数值。
BUF优化参数可参考：增大-B参数值，减小-N 参数值，减小-Z 参数值，减小-SI参数值。需要注意的是-SI参数值越小，占用CPU越高。
目的端优化参数参考：调整-K 参数值。
注意:
以上调优参数及调优方法仅适用于我们的产品：神通数据库(oscar)、kstore、xcluster及MPP5.0。对于第三方数据库不一定适用。
以上参数值增大或减小需根据测试环境调整，如果增大参数值，datamigrate整体性能更差，可通过减小该参数值再测试。
测试没有方向的时候，可以全部都使用默认值，然后只调整某一个参数，两次测试结果做对比，如果性能有比较明显的差异，该参数可能是一个性能热点参数。可以在该参数性能调优的基础上，再设置其他参数进行性能优化测试；如果调整前后，性能基本没有改变，该参数可能不是一个性能热点参数，此时可以将该参数设为一个比较合理的值。比如-SI参数设置太小，可能会很耗CPU；BUF个数太大，或者BUF size太大，可能会占用很多内存。如果这些参数不是性能热点参数，设置为比较合理的值即可。
调优示例¶
数据库导出到文本场景¶
用例基本情况
| 表定义 | create table NoLob_10000000 (a int, b text); |
|---|---|
| 数据行数 | 10000000行，用datamigrate构造数据的命令如下： .datamigrate stype=GENERATE gdatacount=10000000 gcoltype="RAND_INT|0|100,RAND_STR|5|10|10|www.|.com" dtype=OSCAR ddburl=sysdba/szoscar55@localhost:2006/OSRDB_6 ddbtab=NoLob_10000000 |
| 数据库运行环境 | win7系统、4核cpu、8G内存。1TB/4G*2/Intel Core i5-6500千兆网卡。 |
| Datamigrate运行环境 | Linux64、4核cpu、8G内存。1TB/4G*2/Intel Core i5-6500；千兆网卡 |
| 测试用例 | 从数据库获取10000000行（NoLob_10000000表格）到文本文件内 |
测试结果
默认参数：
./datamigrate -y OSCAR -u sysdba/szoscar55@192.168.1.53:2003/OSRDB -t NoLob_10000000 -Y TEXTFILE -F "/opt/NoLob_10000000.txt" -C "," -R "\n"
耗时：200秒
优化1：优化源端-g参数，增大一次性从数据库预取的数据行数：
./datamigrate -y OSCAR -u sysdba/szoscar55@192.168.1.53:2003/OSRDB -t NoLob_10000000 -Y TEXTFILE -F "/opt/NoLob_10000000.txt" -C "," -R "\n" -g 65535
耗时：50秒
优化2：优化buffer池，-B设置为16，buffer大小-Z为1,
./datamigrate -y OSCAR -u sysdba/szoscar55@192.168.1.53:2003/OSRDB -t NoLob_10000000 -Y TEXTFILE -F "/opt/NoLob_10000000.txt" -C "," -R "\n" -g 65535 -B 16 -Z 1
耗时：30秒
优化3：减小调度器轮询查询的时间（-SI的参数值）来优化datamigrate的性能。
./datamigrate -y OSCAR -u sysdba/szoscar55@192.168.1.53:2003/OSRDB -t NoLob_10000000 -Y TEXTFILE -F "/opt/NoLob_10000000.txt" -C "," -R "\n" -g 65535 -B 16 -Z 1 -SI 10
耗时：20秒
结论
用户可通过增大每次从后台获取的行数（-g的参数值），减小buffer的大小（-Z的参数值），增加buffer个数（-B的参数值），减小调度器轮询查询的时间（-SI的参数值）来优化datamigrate的性能。
在服务器上测试：-g 100000 -B 16 -Z 2 -SI 10 性能最优，导出NoLob_10000000表格耗时20s左右（使用默认参数大约需要200s）