Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

写入速度不稳定 #183

Closed
hea opened this issue Sep 5, 2017 · 30 comments
Closed

写入速度不稳定 #183

hea opened this issue Sep 5, 2017 · 30 comments

Comments

@hea
Copy link

hea commented Sep 5, 2017

硬件环境

腾讯云 8核cpu,16G内存,100G SSD本地硬盘,

现象描述

最初写入速度 200w/分钟,几分钟后维持在平均180w/分钟,但写入数据量达到80G后,写入速度下降到50w/分钟

问题

请问这个是合理的下降还是有什么配置可以优化?

感谢360宋同学的回复
单独压测pika slotmigrate 要为 no
因为现在打开codis之后,其实你的所有kv都是存在set数据结构下,这样每一次操作其实在引擎下面会转化成很多自操作,相比关闭之后会慢不少

写入方式为 golang 创建 50个redis客户端,然后50个协程调用test函数

func test(client *redis.Client){
	for true{
		pipe:=client.Pipeline();
		u1 := uuid.NewV4().String()
		key0 := u1+":user:0"
		pipe.Incr(key0);
		pipe.Incr(u1+":user:1");
		pipe.Incr(u1+":user:2");
		pipe.Incr(u1+":user:3");
		pipe.Incr(u1+":user:4");
		//检查是否处理过
		pipe.Exists(u1)
		pipe.Set(u1+":orderId","1",time.Hour*24);
		pipe.LPush(u1+":user:4",
			"{'openId':'6BdpVU','yyyappid':'97107fa23','action':'minus'," +
				"'spend':1000," +
				"'note':'abc'," +
				"'logTime':1503383236932,'userVc':542939}");
		_ ,err:= pipe.Exec();
		if(nil!=err){
			fmt.Println(err)
		}
	}
}

下面是pika的配置信息

# Pika port
port : 9221
# Thread Number
thread-num : 7
# Sync Thread Number
sync-thread-num : 6
# Item count of sync thread queue
sync-buffer-size : 10
# Pika log path
log-path : ./log_1/
# Pika glog level: only INFO and ERROR
loglevel : INFO
# Pika db path
db-path : ./db_1/
# Pika write-buffer-size
write-buffer-size : 268435456
# Pika timeout
timeout : 60
# Requirepass
requirepass : 
# Masterauth
masterauth : 
# Userpass
userpass : 
# User Blacklist
userblacklist : 
# Dump Prefix
dump-prefix : 
# daemonize  [yes | no]
#daemonize : yes
# slotmigrate  [yes | no]
slotmigrate : yes
# Dump Path
dump-path : ./dump_1/
# Expire-dump-days
dump-expire : 0
# pidfile Path
pidfile : ./pika.pid
# Max Connection
maxclients : 20000
# the per file size of sst to compact, defalut is 2M
target-file-size-base : 20971520
# Expire-logs-days
expire-logs-days : 7
# Expire-logs-nums
expire-logs-nums : 10
# Root-connection-num
root-connection-num : 2
# Slowlog-log-slower-than
slowlog-log-slower-than : 10000
# slave-read-only(yes/no, 1/0)
slave-read-only : false
# Pika db sync path
db-sync-path : ./dbsync_1/
# db sync speed(MB) max is set to 125MB, min is set to 0, and if below 0 or above 125, the value will be adjust to 125
db-sync-speed : 125
# network interface
# network-interface : eth1
# replication
# slaveof : master-ip:master-port
#
# CronTask, format: start-end/ratio, like 02-04/60, pika will check to schedule compaction between 2 to 4 o'clock everyday
#                   if the freesize/disksize > 60%. NOTICE:if compact-interval is set, compact-cron will be mask and disable.
# compact-cron :
#
# Compact-interval, format: interval/ratio, like 6/60, pika will check to schedule compaction every 6 hours,
#                           if the freesize/disksize > 60%. NOTICE:compact-interval is prior than compact-cron;
# compact-interval :

###################
## Critical Settings
###################
# binlog file size: default is 100M,  limited in [1K, 2G]
binlog-file-size : 104857600
# Compression
compression : snappy
# max-background-flushes: default is 1, limited in [1, 4]
max-background-flushes : 1
# max-background-compactions: default is 1, limited in [1, 4]
max-background-compactions : 2
# max-cache-files default is 5000
max-cache-files : 5000
# max_bytes_for_level_multiplier: default is 10, you can change it to 5
max-bytes-for-level-multiplier : 10
@baotiao
Copy link
Contributor

baotiao commented Sep 5, 2017

这个下降是在预期范围内的, 因为数据打了以后, 底层的引擎也需要做数据的compact 等等操作

@hea
Copy link
Author

hea commented Sep 5, 2017

感谢回复,请问如果磁盘使用量在80%以下,能不能保障这个平均写入速度维持在180w/分钟?

@tigerzhang
Copy link

@hea 写入速度依赖于磁盘的 IOPS、rocksdb 的 compact 频率。跟磁盘用量关系不大。

@hea
Copy link
Author

hea commented Sep 5, 2017

@tigerzhang 感谢回复,有什么方法可以避免这种问题吗,比如说,单台机器的数据量应该在50g左右,不宜过高,或者把compact 的任务调整到凌晨访问量小的时候

@baotiao
Copy link
Contributor

baotiao commented Sep 5, 2017

@tigerzhang 说得对.

@baotiao
Copy link
Contributor

baotiao commented Sep 5, 2017

@hea 可以这样, 或者你可以加大点内存. 也一定可以增加性能

@hea
Copy link
Author

hea commented Sep 5, 2017

@baotiao 感谢回复,我把任务调整到凌晨,单机数据还80g左右,内存加到32G再试试

@baotiao
Copy link
Contributor

baotiao commented Sep 5, 2017

嗯 有问题随时联系我们 哈哈

@baotiao
Copy link
Contributor

baotiao commented Sep 5, 2017

你这个数据80G 的话 其实存在redis 里面的话会有320G 左右

@hea
Copy link
Author

hea commented Sep 5, 2017

@baotiao

你这个数据80G 的话 其实存在redis 里面的话会有320G 左右

请问 这个是说reids碎片率太高,还是说pika的80g是压缩后的,把320G的数据压缩到了80G

@hea
Copy link
Author

hea commented Sep 5, 2017

说下目前的测试情况

硬件环境

腾讯云 8核cpu,32G内存,100G SSD本地硬盘,

现象描述

最初写入速度 200w/分钟,之后每分钟的量都在变,有下降的趋势,下面是找了几条(不定时更新数据)

dbsize=18507901 上1分钟内写入量 1570535 | Tue Sep  5 13:23:01 CST 2017
dbsize=141557859 上1分钟内写入量 1491574 | Tue Sep  5 14:52:01 CST 2017
dbsize=189130896 上1分钟内写入量 1146394 | Tue Sep  5 15:31:01 CST 2017
dbsize=200692630 上1分钟内写入量 973103 | Tue Sep  5 15:41:01 CST 2017
dbsize=213779411 上1分钟内写入量 1393728 | Tue Sep  5 15:52:01 CST 2017
dbsize=218438846 上1分钟内写入量 1158135 | Tue Sep  5 15:56:01 CST 2017
dbsize=408409747 上1分钟内写入量 900074 | Tue Sep  5 18:39:01 CST 2017
dbsize=422770228 上1分钟内写入量 1506580 | Tue Sep  5 18:51:01 CST 2017
dbsize=433132272 上1分钟内写入量 1191457 | Tue Sep  5 18:59:01 CST 2017
dbsize=448407540 上1分钟内写入量 1090942 | Tue Sep  5 19:12:01 CST 2017
dbsize=697821337 上1分钟内写入量 849550 | Tue Sep  5 23:25:01 CST 2017
dbsize=745815722 上1分钟内写入量 756401 | Wed Sep  6 00:23:01 CST 2017
dbsize=823919557 上1分钟内写入量 838631 | Wed Sep  6 01:59:01 CST 2017
dbsize=879938865 上1分钟内写入量 791560 | Wed Sep  6 03:10:01 CST 2017
dbsize=1037078380 上1分钟内写入量 691494 | Wed Sep  6 06:40:02 CST 2017
dbsize=1130132251 上1分钟内写入量 646315 | Wed Sep  6 08:54:02 CST 2017
dbsize=1146616263 上1分钟内写入量 632650 | Wed Sep  6 09:19:01 CST 2017
dbsize=1173194893 上1分钟内写入量 704875 | Wed Sep  6 09:59:01 CST 2017
dbsize=1175742215 上1分钟内写入量 601661 | Wed Sep  6 10:03:02 CST 2017

配置文件同上文比较只修改了

compact-cron : 02-04/90

@baotiao
Copy link
Contributor

baotiao commented Sep 5, 2017

这个是我们实际测试的一个业务的线上数据, redis和 pika 的压缩比能够达到 1:4

@baotiao
Copy link
Contributor

baotiao commented Sep 5, 2017

@hea 能否用 iostat -xm 1 或者 dstat 看一下目前的磁盘IO, 以及你的单个value 的大小是多大

@hea
Copy link
Author

hea commented Sep 5, 2017

数据说明,这个value的大小应该没问题

image

安装工具包

yum install sysstat

执行命令

iostat -xm 1
Linux 2.6.32-504.30.3.el6.x86_64 (VM_49_188_centos) 	09/05/2017 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          62.18    0.00   19.80    0.03    0.00   17.98

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.03     6.65    3.02    1.52     0.11     0.03    65.89     0.01    1.41    0.74    2.71   0.43   0.19
vdb               0.05  6440.26    1.62   78.97     0.06    24.89   634.00     0.16    1.99    0.34    2.03   0.17   1.34

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          74.00    0.00   17.12    0.00    0.00    8.88

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00  5107.00    0.00   70.00     0.00    20.22   591.66     0.09    1.30    0.00    1.30   0.33   2.30

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          74.34    0.00   17.15    0.00    0.00    8.51

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     2.00    0.00    5.00     0.00     0.03    11.20     0.02    4.80    0.00    4.80   1.60   0.80
vdb               0.00  8540.00    0.00   95.00     0.00    30.30   653.22     0.12    1.19    0.00    1.19   0.21   2.00

@hea
Copy link
Author

hea commented Sep 6, 2017

跑了不到12个小时,硬盘不足10g就停了,这个下降看着是很明显的

dbsize=18507901 上1分钟内写入量 1570535 | Tue Sep  5 13:23:01 CST 2017
dbsize=433132272 上1分钟内写入量 1191457 | Tue Sep  5 18:59:01 CST 2017
dbsize=448407540 上1分钟内写入量 1090942 | Tue Sep  5 19:12:01 CST 2017
dbsize=697821337 上1分钟内写入量 849550 | Tue Sep  5 23:25:01 CST 2017
dbsize=745815722 上1分钟内写入量 756401 | Wed Sep  6 00:23:01 CST 2017
dbsize=823919557 上1分钟内写入量 838631 | Wed Sep  6 01:59:01 CST 2017
dbsize=879938865 上1分钟内写入量 791560 | Wed Sep  6 03:10:01 CST 2017
dbsize=1037078380 上1分钟内写入量 691494 | Wed Sep  6 06:40:02 CST 2017
dbsize=1130132251 上1分钟内写入量 646315 | Wed Sep  6 08:54:02 CST 2017
dbsize=1146616263 上1分钟内写入量 632650 | Wed Sep  6 09:19:01 CST 2017
dbsize=1173194893 上1分钟内写入量 704875 | Wed Sep  6 09:59:01 CST 2017
dbsize=1175742215 上1分钟内写入量 601661 | Wed Sep  6 10:03:02 CST 2017

iostat

[root@VM_49_188_centos ~]# iostat -xm 1
Linux 2.6.32-504.30.3.el6.x86_64 (VM_49_188_centos) 	09/06/2017 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          48.90    0.00   15.79    7.88    0.00   27.43

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.02     5.62    2.19    1.53     0.04     0.03    39.51     0.00    1.17    0.57    2.03   0.38   0.14
vdb               0.08  6310.12 6281.76   99.98    35.36    24.89    19.33     1.71    0.27    0.24    2.02   0.09  56.30

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          24.78    0.00    9.56   15.47    0.00   50.19

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     5.00 15080.00    4.00    83.22     0.04    11.30     3.09    0.21    0.21    0.00   0.07  98.40

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          25.69    0.00    8.69   16.50    0.00   49.12

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     0.00 14637.00    1.00    80.74     0.00    11.30     2.99    0.21    0.21    1.00   0.07  97.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          23.65    0.00    8.68   14.59    0.00   53.08

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     1.00    0.00    2.00     0.00     0.01    12.00     0.01    3.00    0.00    3.00   1.50   0.30
vdb               0.00     1.00 14055.00    3.00    77.62     0.02    11.31     3.17    0.23    0.23    1.00   0.07  97.70

image

@hea
Copy link
Author

hea commented Sep 6, 2017

感谢360 宋同学的分析

1. 打开compact时,写入变慢是因为rocksdb的compact时你的磁盘util基本已经占满,这时候读写都会变慢;2. 关闭compact时,因为的测试的接口包含类似incr这种底层实现需要进行Get的接口,所以关闭compact后,随着写入的进行,Get的速度回越来越慢,这也就导致了你的测试用例越跑越慢
你试试:关闭rocksdb的compact,调大rocksdb的stall及stop阈值,然后你的测试程序中只进行set,看看速度是否稳定
根本原因还是盘的util跑满了

@hea
Copy link
Author

hea commented Sep 6, 2017

50个 客户端 ssdb 压测

func ssdbTestSet(db *ssdb.Client ) {
	for(true){
		u1 := uuid.NewV4().String()
		_,err := db.Do("set", "key"+u1, "1kvalue")
		if(nil != err){
			log.Println("err",err)
		}else{

		}
	}
}

取ssdb info里的binlogs.max_seq

dbsize= 2589389 上1分钟内写入量 1544697 | Wed Sep  6 16:14:01 CST 2017
dbsize= 16149505 上1分钟内写入量 1372101 | Wed Sep  6 16:23:01 CST 2017
dbsize= 17349462 上1分钟内写入量 1199957 | Wed Sep  6 16:24:01 CST 2017
dbsize= 18589615 上1分钟内写入量 1240153 | Wed Sep  6 16:25:01 CST 2017
dbsize= 20892786 上1分钟内写入量 1111741 | Wed Sep  6 16:27:01 CST 2017
dbsize= 23500244 上1分钟内写入量 1443720 | Wed Sep  6 16:29:01 CST 2017
dbsize= 24790356 上1分钟内写入量 1290112 | Wed Sep  6 16:30:01 CST 2017
dbsize= 25837801 上1分钟内写入量 1047445 | Wed Sep  6 16:31:02 CST 2017
dbsize= 26919168 上1分钟内写入量 1081367 | Wed Sep  6 16:32:01 CST 2017
dbsize= 27738174 上1分钟内写入量 819006 | Wed Sep  6 16:33:01 CST 2017
dbsize= 32297319 上1分钟内写入量 1428485 | Wed Sep  6 16:37:01 CST 2017
dbsize= 33600410 上1分钟内写入量 1303091 | Wed Sep  6 16:38:01 CST 2017
dbsize= 35702738 上1分钟内写入量 895724 | Wed Sep  6 16:40:01 CST 2017
dbsize= 36794168 上1分钟内写入量 1091430 | Wed Sep  6 16:41:01 CST 2017
dbsize= 41444746 上1分钟内写入量 1418323 | Wed Sep  6 16:45:01 CST 2017
dbsize= 42547682 上1分钟内写入量 1102936 | Wed Sep  6 16:46:01 CST 2017
dbsize= 45495224 上1分钟内写入量 1021788 | Wed Sep  6 16:49:01 CST 2017
dbsize= 46378926 上1分钟内写入量 883702 | Wed Sep  6 16:50:01 CST 2017
dbsize= 47098691 上1分钟内写入量 719765 | Wed Sep  6 16:51:01 CST 2017
dbsize= 61676925 上1分钟内写入量 1476779 | Wed Sep  6 17:05:01 CST 2017

@hea
Copy link
Author

hea commented Sep 7, 2017

ssdb 和 pika的对比,如果方式有问题,请多指教

ssdb 硬件环境 腾讯云主机 8核32G 100G SSD本地盘
pika 硬件环境 腾讯云主机 8核32G 200G SSD本地盘

在最后10分钟的时候,ssdb平均能到80w/分钟,pika平均70w/分钟

ssdb结果 取ssdb info里的binlogs.max_seq,只有set操作

dbsize= 2589389 上1分钟内写入量 1544697 | Wed Sep 6 16:14:01 CST 2017
dbsize= 4142666 上1分钟内写入量 1553277 | Wed Sep 6 16:15:01 CST 2017
dbsize= 5670150 上1分钟内写入量 1527484 | Wed Sep 6 16:16:01 CST 2017
dbsize= 7189285 上1分钟内写入量 1519135 | Wed Sep 6 16:17:01 CST 2017
dbsize= 8718772 上1分钟内写入量 1529487 | Wed Sep 6 16:18:01 CST 2017
dbsize= 10213071 上1分钟内写入量 1494299 | Wed Sep 6 16:19:01 CST 2017
dbsize= 11736291 上1分钟内写入量 1523220 | Wed Sep 6 16:20:01 CST 2017
dbsize= 13287728 上1分钟内写入量 1551437 | Wed Sep 6 16:21:01 CST 2017
dbsize= 14777404 上1分钟内写入量 1489676 | Wed Sep 6 16:22:01 CST 2017
dbsize= 16149505 上1分钟内写入量 1372101 | Wed Sep 6 16:23:01 CST 2017

dbsize= 923733909 上1分钟内写入量 845771 | Thu Sep 7 10:17:01 CST 2017
dbsize= 923787529 上1分钟内写入量 53620 | Thu Sep 7 10:18:01 CST 2017
dbsize= 924615661 上1分钟内写入量 828132 | Thu Sep 7 10:19:01 CST 2017
dbsize= 925262978 上1分钟内写入量 647317 | Thu Sep 7 10:20:01 CST 2017
dbsize= 925876848 上1分钟内写入量 613870 | Thu Sep 7 10:21:01 CST 2017
dbsize= 926785196 上1分钟内写入量 908348 | Thu Sep 7 10:22:01 CST 2017
dbsize= 927636954 上1分钟内写入量 851758 | Thu Sep 7 10:23:01 CST 2017
dbsize= 928458872 上1分钟内写入量 821918 | Thu Sep 7 10:24:01 CST 2017
dbsize= 929324221 上1分钟内写入量 865349 | Thu Sep 7 10:25:01 CST 2017
dbsize= 929949002 上1分钟内写入量 624781 | Thu Sep 7 10:26:01 CST 2017

pika结果 开启了cosid(我们的业务最终需要放到codis里),取dbsize,pipeline 只有set操作,set的值和ssdb set的值一样

dbsize=3343121 上1分钟内写入量 3049759 | Wed Sep 6 18:42:01 CST 2017
dbsize=5864640 上1分钟内写入量 2521519 | Wed Sep 6 18:43:01 CST 2017
dbsize=8374521 上1分钟内写入量 2509881 | Wed Sep 6 18:44:01 CST 2017
dbsize=10586053 上1分钟内写入量 2211532 | Wed Sep 6 18:45:01 CST 2017
dbsize=12651430 上1分钟内写入量 2065377 | Wed Sep 6 18:46:01 CST 2017
dbsize=14904522 上1分钟内写入量 2253092 | Wed Sep 6 18:47:01 CST 2017
dbsize=17130624 上1分钟内写入量 2226102 | Wed Sep 6 18:48:01 CST 2017
dbsize=19417898 上1分钟内写入量 2287274 | Wed Sep 6 18:49:01 CST 2017
dbsize=21649496 上1分钟内写入量 2231598 | Wed Sep 6 18:50:01 CST 2017
dbsize=23593982 上1分钟内写入量 1944486 | Wed Sep 6 18:51:01 CST 2017

dbsize=1057203847 上1分钟内写入量 719243 | Thu Sep 7 10:18:01 CST 2017
dbsize=1057925347 上1分钟内写入量 721500 | Thu Sep 7 10:19:01 CST 2017
dbsize=1058622397 上1分钟内写入量 697050 | Thu Sep 7 10:20:01 CST 2017
dbsize=1059313161 上1分钟内写入量 690764 | Thu Sep 7 10:21:01 CST 2017
dbsize=1060042433 上1分钟内写入量 729272 | Thu Sep 7 10:22:01 CST 2017
dbsize=1060793083 上1分钟内写入量 750650 | Thu Sep 7 10:23:01 CST 2017
dbsize=1061552410 上1分钟内写入量 759327 | Thu Sep 7 10:24:01 CST 2017
dbsize=1062289297 上1分钟内写入量 736887 | Thu Sep 7 10:25:01 CST 2017
dbsize=1062992361 上1分钟内写入量 703064 | Thu Sep 7 10:26:01 CST 2017

@hea
Copy link
Author

hea commented Sep 8, 2017

pika set 性能测试

硬件环境

pika100 硬件环境 腾讯云主机 8核32G 100G SSD本地盘
pika200 硬件环境 腾讯云主机 8核32G 200G SSD本地盘

测试方法

50个redis客户端连接,set的key为uuid产生,value大小1k

说明

pika slotmigrate 为 no(关闭codis迁移功能),结合上面的测试,slotmigrate 的开关对性能影响很大,但是本次测试的时间不足12小时,上面的测试是16个小时,继续跑下去,并不确定性能下降到什么程度,后续还在测试。

硬盘越大性能越好,同样是腾讯云的本地ssd盘,200G的写入性能也比100G的要高,单从set操作上看,每分钟差60w左右,不过都伴随这写的越多,写的也越慢

取数方法为每分钟取一次info中的total_commands_processed

100G total_commands_processed=5019787 上1分钟内写入量 1866623 | 200G total_commands_processed=7830353 上1分钟内写入量 3124965 | Thu Sep  7 17:53:01 CST 2017
100G total_commands_processed=6929445 上1分钟内写入量 1909658 | 200G total_commands_processed=10982429 上1分钟内写入量 3152076 | Thu Sep  7 17:54:01 CST 2017
100G total_commands_processed=8838998 上1分钟内写入量 1909553 | 200G total_commands_processed=14170022 上1分钟内写入量 3187593 | Thu Sep  7 17:55:01 CST 2017
100G total_commands_processed=10723491 上1分钟内写入量 1884493 | 200G total_commands_processed=17279516 上1分钟内写入量 3109494 | Thu Sep  7 17:56:01 CST 2017
100G total_commands_processed=12575572 上1分钟内写入量 1852081 | 200G total_commands_processed=20487395 上1分钟内写入量 3207879 | Thu Sep  7 17:57:01 CST 2017
100G total_commands_processed=14431196 上1分钟内写入量 1855624 | 200G total_commands_processed=23544871 上1分钟内写入量 3057476 | Thu Sep  7 17:58:01 CST 2017
100G total_commands_processed=16320416 上1分钟内写入量 1889220 | 200G total_commands_processed=26374820 上1分钟内写入量 2829949 | Thu Sep  7 17:59:01 CST 2017
100G total_commands_processed=18208010 上1分钟内写入量 1887594 | 200G total_commands_processed=28934956 上1分钟内写入量 2560136 | Thu Sep  7 18:00:01 CST 2017
100G total_commands_processed=20083973 上1分钟内写入量 1875963 | 200G total_commands_processed=31508009 上1分钟内写入量 2573053 | Thu Sep  7 18:01:01 CST 2017
100G total_commands_processed=21967962 上1分钟内写入量 1883989 | 200G total_commands_processed=34161156 上1分钟内写入量 2653147 | Thu Sep  7 18:02:01 CST 2017

100G total_commands_processed=859283508 上1分钟内写入量 1036189 | 200G total_commands_processed=1064633637 上1分钟内写入量 1543074 | Fri Sep  8 04:00:01 CST 2017
100G total_commands_processed=860357122 上1分钟内写入量 1073614 | 200G total_commands_processed=1066342396 上1分钟内写入量 1708759 | Fri Sep  8 04:01:01 CST 2017
100G total_commands_processed=861470307 上1分钟内写入量 1113185 | 200G total_commands_processed=1067920327 上1分钟内写入量 1577931 | Fri Sep  8 04:02:01 CST 2017
100G total_commands_processed=862590233 上1分钟内写入量 1119926 | 200G total_commands_processed=1070080196 上1分钟内写入量 2159869 | Fri Sep  8 04:03:01 CST 2017
100G total_commands_processed=863708001 上1分钟内写入量 1117768 | 200G total_commands_processed=1071638310 上1分钟内写入量 1558114 | Fri Sep  8 04:04:01 CST 2017
100G total_commands_processed=864613048 上1分钟内写入量 905047 | 200G total_commands_processed=1072871948 上1分钟内写入量 1233638 | Fri Sep  8 04:05:01 CST 2017
100G total_commands_processed=865879233 上1分钟内写入量 1266185 | 200G total_commands_processed=1074362872 上1分钟内写入量 1490924 | Fri Sep  8 04:06:01 CST 2017
100G total_commands_processed=867036487 上1分钟内写入量 1157254 | 200G total_commands_processed=1075747083 上1分钟内写入量 1384211 | Fri Sep  8 04:07:02 CST 2017
100G total_commands_processed=868073003 上1分钟内写入量 1036516 | 200G total_commands_processed=1076923809 上1分钟内写入量 1176726 | Fri Sep  8 04:08:01 CST 2017
100G total_commands_processed=869339127 上1分钟内写入量 1266124 | 200G total_commands_processed=1078564088 上1分钟内写入量 1640279 | Fri Sep  8 04:09:01 CST 2017

@baotiao
Copy link
Contributor

baotiao commented Sep 8, 2017

@hea 那就是不写slot 性能其实比 ssdb 好得多.. 120w/分钟

@hea
Copy link
Author

hea commented Sep 11, 2017

pika set 性能测试

环境

pika2.2.5
硬件环境 腾讯云主机 8核32G 200G SSD本地盘

测试方法

50个redis客户端连接,set的key为uuid产生,value大小1k

说明

pika slotmigrate 为 no(关闭codis迁移功能)
取数方法为每分钟取一次info中的total_commands_processed

问题

测试21小时左右,偶尔出现写入速度成倍下降,不确定是什么原因。

感谢360陈同学的回答

这个属于正常 底下引擎有 compact 的时候 磁盘io 占满了
所以对写入有影响
这个 测试 是底下自动触发的 比较细..
1243540 / 60 = 20725 数据的大小是 1k 也就是 上层你看到的io 大概是 20.725MB/s 那么对于底下的引擎来说, 由于写放大的存在, 所以磁盘io 差不多是 200 MB/s 对于你这个磁盘的性能是正常的了

留疑:由于从zabbix里没有看到凸起的io,后续会再进行测试,验证这个结论

最初稳定的3分钟
200G 总量=12772614 上1分钟内写入量 2763112 | Fri Sep  8 17:27:01 CST 2017
200G 总量=15516056 上1分钟内写入量 2743442 | Fri Sep  8 17:28:01 CST 2017
200G 总量=18301884 上1分钟内写入量 2785828 | Fri Sep  8 17:29:01 CST 2017
#中间时段某3分钟,有成倍的下降
200G 总量=510494082 上1分钟内写入量 2563931 | Fri Sep  8 21:21:01 CST 2017
200G 总量=511110047 上1分钟内写入量 615965 | Fri Sep  8 21:22:01 CST 2017
200G 总量=513679125 上1分钟内写入量 2569078 | Fri Sep  8 21:23:01 CST 2017
# 中间时段某3分钟,有成倍的下降
200G 总量=668363689 上1分钟内写入量 2088984 | Fri Sep  8 22:49:01 CST 2017
200G 总量=669299990 上1分钟内写入量 936301 | Fri Sep  8 22:50:01 CST 2017
200G 总量=671925525 上1分钟内写入量 2625535 | Fri Sep  8 22:51:01 CST 2017
# 中间时段某3分钟,有成倍的下降
200G 总量=1804138303 上1分钟内写入量 1394924 | Sat Sep  9 13:50:01 CST 2017
200G 总量=1804811358 上1分钟内写入量 673055 | Sat Sep  9 13:51:01 CST 2017
200G 总量=1806179368 上1分钟内写入量 1368010 | Sat Sep  9 13:52:01 CST 2017
最后3分钟,下一分钟磁盘已满
200G 总量=1824903949 上1分钟内写入量 1273636 | Sat Sep  9 14:08:01 CST 2017
200G 总量=1826270497 上1分钟内写入量 1366548 | Sat Sep  9 14:09:01 CST 2017
200G 总量=1827514037 上1分钟内写入量 1243540 | Sat Sep  9 14:10:01 CST 2017

@baotiao
Copy link
Contributor

baotiao commented Sep 11, 2017

@hea
1243540 / 60 = 20725 数据的大小是 1k 也就是 上层你看到的io 大概是 20.725MB/s 那么对于底下的引擎来说, 由于写放大的存在, 所以磁盘io 差不多是 200 MB/s 对于你这个磁盘的性能是正常的了

@hea
Copy link
Author

hea commented Sep 11, 2017

合并时,磁盘跟不上了
image

Mon Sep 11 15:58:45 CST 2017
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          17.96    0.00    9.80    0.38    0.00   71.86

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00 21046.00  478.00  241.00    16.46    83.15   283.73     0.80    1.11    0.32    2.66   0.10   7.40

Mon Sep 11 15:58:46 CST 2017
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.31    0.00   10.21    0.12    0.00   71.36

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00 10182.00  366.00  121.00    13.48    40.25   225.94     0.42    0.86    0.28    2.63   0.10   4.80

Mon Sep 11 15:58:47 CST 2017
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.73    0.00    9.86    0.12    0.00   71.29

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    1.00     0.00     0.00     8.00     0.00    3.00    0.00    3.00   3.00   0.30
vdb               0.00 19405.00    0.00  219.00     0.00    76.66   716.86     0.52    2.37    0.00    2.37   0.14   3.10

Mon Sep 11 15:58:48 CST 2017
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.70    0.00    9.66    0.13    0.00   71.52

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00 48014.00    0.00  372.00     0.00   134.08   738.15     3.72    7.15    0.00    7.15   0.17   6.40

Mon Sep 11 15:58:49 CST 2017
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          16.86    0.00    9.81    1.13    0.00   72.20

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               2.00 55765.00  247.00  647.00     9.27   275.29   651.87    14.65   17.57    1.04   23.88   0.18  15.90

Mon Sep 11 15:58:50 CST 2017
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.30    0.00    9.77    0.25    0.00   71.68

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00 15772.00  394.00  182.00    15.10    62.32   275.28     0.53    0.91    0.27    2.32   0.09   5.00

@hea
Copy link
Author

hea commented Sep 12, 2017

环境

腾讯云 8核32G 200SSD本地盘

说明

pika slotmigrate 为 no(关闭codis迁移功能)
取数方法为每分钟取一次info中的total_commands_processed
时间 9月11号 17:30 到 9月12号 11点

50个客户端写入pika

func test(client *redis.Client){
	for true{
		pipe:=client.Pipeline();
		u1 := uuid.NewV4().String()
		key0 := u1+":user:0"
		pipe.Incr(key0);
		pipe.Incr(u1+":user:1");
		pipe.Incr(u1+":user:2");
		pipe.Incr(u1+":user:3");
		pipe.Incr(u1+":user:4");
		//检查是否处理过
		pipe.Exists(u1)
		pipe.Set(u1+":orderId","1",time.Hour*24);
		pipe.LPush(u1+":user:4",
			"{'openId':'5C2Y0__vYLYG0ahd6BdpVU','yyyappid':'97107fa23','action':'minus'," +
				"'spend':1000," +
				"'note':'note'," +
				"'logTime':1503383236932,'userVc':542939,'clientName':'search','clientBusinessName':'game'}");
		_ ,err:= pipe.Exec();
		if(nil!=err){
			fmt.Println(err)
		}
	}
}

主机CPU监控
image

image

image

写入统计

最初的几分钟  这个时候 io的%util 大部分为0
200G 总量=46547437 上1s内写入量 70879 | 2017年 09月 11日 星期一 17:30:00 CST
200G 总量=46616569 上1s内写入量 69132 | 2017年 09月 11日 星期一 17:30:01 CST
200G 总量=46686622 上1s内写入量 70053 | 2017年 09月 11日 星期一 17:30:02 CST

在最低的时候  这个时候 io的%util 在3 左右
200G 总量=1646981331 上1s内写入量 545 | 2017年 09月 12日 星期二 04:29:55 CST
200G 总量=1646982132 上1s内写入量 801 | 2017年 09月 12日 星期二 04:29:59 CST
200G 总量=1646982957 上1s内写入量 825 | 2017年 09月 12日 星期二 04:30:01 CST

后来趋于平稳 这个时候 io的%util 在40 左右
200G 总量=2227539568 上1s内写入量 33823 | 2017年 09月 12日 星期二 11:11:31 CST
200G 总量=2227572857 上1s内写入量 33289 | 2017年 09月 12日 星期二 11:11:32 CST
200G 总量=2227610149 上1s内写入量 37292 | 2017年 09月 12日 星期二 11:11:33 CST

@baotiao
Copy link
Contributor

baotiao commented Sep 12, 2017

@hea

@hea
Copy link
Author

hea commented Sep 13, 2017

环境

腾讯云 8核32G 200SSD本地盘

说明

pika slotmigrate 为 no(关闭codis迁移功能)
取数方法为每分钟取一次info中的total_commands_processed
时间 9月12号 22 到 9月13号 10点

感谢 KernelMaker的分析与建议

list的引擎 level 0文件很多,stall会让写变慢
level 0多的话,读性能也会有影响,像你的incr,exists,lpush等都有读操作
看你list的log,写入量还是很大的,这样短时间内level 0会积攒很多,然后一次性compact到level 1,然后level 1变大跟多,导致level 1在自动compact的score高,然后自动compact一直在做高score的level 1,迟迟不搞level 0,然后level 0挤压,发生stall
这好像就是为什么你上层写入一会快一会慢

我对比了一下前后日志,应该就是我昨天说的那个原因,写入量比较大,在Level 1较大时对应的score大于Level 0的score,导致Level 0的compact迟迟做不了,然后上层继续写入造成Level 0积压从而stall,提高compact线程数之后,Level 1 -> Level 2会加速,缓解了Level 0的积压,不会发生stall,所以你上层也就不会抖动了
这一版pika的最大compact线程数限制在4个,下一版我改大一点

配置文件调整

max-background-compactions : 4

目前测试的结果比上次好很多

200G 总量=2418403 上1s内写入量 91330 | 2017年 09月 12日 星期二 22:10:30 CST
200G 总量=2509546 上1s内写入量 91143 | 2017年 09月 12日 星期二 22:10:32 CST
200G 总量=2601159 上1s内写入量 91613 | 2017年 09月 12日 星期二 22:10:33 CST

200G 总量=1209428475 上1s内写入量 40408 | 2017年 09月 13日 星期三 04:32:00 CST
200G 总量=1209465791 上1s内写入量 37316 | 2017年 09月 13日 星期三 04:32:01 CST
200G 总量=1209506445 上1s内写入量 40654 | 2017年 09月 13日 星期三 04:32:02 CST

200G 总量=2049403726 上1s内写入量 34517 | 2017年 09月 13日 星期三 10:36:13 CST
200G 总量=2049443609 上1s内写入量 39883 | 2017年 09月 13日 星期三 10:36:14 CST
200G 总量=2049484023 上1s内写入量 40414 | 2017年 09月 13日 星期三 10:36:15 CST

@baotiao
Copy link
Contributor

baotiao commented Sep 13, 2017

@hea @KernelMaker 这个结果非常好呢..

@Hisoka-J
Copy link
Collaborator

@hea
非常棒的测试

@hea
Copy link
Author

hea commented Sep 13, 2017

感谢 baotiao 和 KernelMaker 对测试的支持与帮助

总结

  1. 如果不需要随时迁移数据的功能,挂到codis后面的pika 配置中slotmigrate 也可以为no,等需要迁移的时候再设置为yes(没有实际测试过,挂到codis后的测试如果有问题会新开issue)。

  2. 如果由于compact导致的上层应用有延迟,可以调整max-background-compactions参数,2.2.5的版本最大为4

测试结束

将近20小时的持续写入(api有读取操作)
目前磁盘剩余108G,写入稳定在3w/s左右, %util 70 左右,pika性能满足业务需要

Wed Sep 13 15:51:02 CST 2017
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          56.45    0.00   17.65    5.38    0.00   20.53

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00   442.00 4927.00   22.00    33.52     1.81    14.62     1.75    0.35    0.35    0.32   0.14  71.00

Wed Sep 13 15:51:04 CST 2017
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          56.48    0.00   18.20    4.36    0.00   20.95

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00 10350.00 4733.00  156.00    31.82    41.04    30.52     1.53    0.31    0.27    1.69   0.13  63.60

Wed Sep 13 15:51:05 CST 2017
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          53.59    0.00   17.78    4.04    0.00   24.59

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00  7404.00 6831.00  117.00    38.97    29.38    20.15     1.53    0.22    0.20    1.53   0.10  70.90

@baotiao
Copy link
Contributor

baotiao commented Sep 13, 2017

@hea 赞.
等你上线 我们把你们加到 user list 里面. 这是我们见过在云服务器上最详细的测试了..

@hea hea closed this as completed Sep 13, 2017
AlexStocks pushed a commit that referenced this issue Jul 26, 2023
…ess (#1805)

* define rsync related header file and proto

* feat:add throttle (#167)

* add_throttle

* feat: implement rsync network tansform (#169)

implement rsync network transfer

Co-authored-by: wangshaoyi <[email protected]>

* fix action (#171)

* fix action

* fix

* feat: add load local meta file (#175)

* add load meta file

* [feat] add rsync client/server code (#177)

* implement rsync network transfer

* add rsyncclient to syncslaveslot (#182)

add rsyncclient to syncslaveslot

* feat: add read meta file and data (#179)

* add read meta file and data

* fix compile error (#183)

* fix bug

* add rsyncclient to syncslaveslot

* fix compile error

* fix compile error

---------

Co-authored-by: wangshaoyi <[email protected]>

* fix compile error (#184)

* fix bug

* optimize: add_throttle (#189)

optimize throttle

* rsyncclient periodically flush meta table (#192)

rsyncclient periodically flush meta table

* change rsync response (#190)

* change rsync response

* add debug log for test

* fix rsync client/server bugs

* fix bugs

* add debug log for test

* fix bugs

* fix bugs

* fix bugs

* rix rsync bugs (#194)

* fix pika rsync bug

* fix bugs

* fix bugs

* fix bugs 1

* fix bugs

* fix rsync bugs (#195)

* add debug log for test

* fix rsync client/server bugs

* fix bugs

* add debug log for test

* fix bugs

* fix bugs

* fix bugs

* fix bugs

* fix bugs

* fix bugs 1

* fix bugs

---------

Co-authored-by: wangshaoyi <[email protected]>

* remove unused code

* remove unused code

* remove unused code

* remove unused code

* add copyright

* fix by review comments (#213)

Co-authored-by: wangshaoyi <[email protected]>

* fix by review comments (#214)

* fix by review comments
Co-authored-by: wangshaoyi <[email protected]>

* fix by review comments (#216)

* fix by review comments
---------

Co-authored-by: wangshaoyi <[email protected]>

* Optimize rsync wangsy (#217)

* fix by review comments

Co-authored-by: wangshaoyi <[email protected]>

* fix by review comments (#218)

* fix by review comments
---------

Co-authored-by: wangshaoyi <[email protected]>

---------

Co-authored-by: wangshaoyi <[email protected]>
Co-authored-by: Yuecai Liu <[email protected]>
Co-authored-by: chejinge <[email protected]>
Co-authored-by: luky116 <[email protected]>
bigdaronlee163 pushed a commit to bigdaronlee163/pika that referenced this issue Jun 8, 2024
…ess (OpenAtomFoundation#1805)

* define rsync related header file and proto

* feat:add throttle (OpenAtomFoundation#167)

* add_throttle

* feat: implement rsync network tansform (OpenAtomFoundation#169)

implement rsync network transfer

Co-authored-by: wangshaoyi <[email protected]>

* fix action (OpenAtomFoundation#171)

* fix action

* fix

* feat: add load local meta file (OpenAtomFoundation#175)

* add load meta file

* [feat] add rsync client/server code (OpenAtomFoundation#177)

* implement rsync network transfer

* add rsyncclient to syncslaveslot (OpenAtomFoundation#182)

add rsyncclient to syncslaveslot

* feat: add read meta file and data (OpenAtomFoundation#179)

* add read meta file and data

* fix compile error (OpenAtomFoundation#183)

* fix bug

* add rsyncclient to syncslaveslot

* fix compile error

* fix compile error

---------

Co-authored-by: wangshaoyi <[email protected]>

* fix compile error (OpenAtomFoundation#184)

* fix bug

* optimize: add_throttle (OpenAtomFoundation#189)

optimize throttle

* rsyncclient periodically flush meta table (OpenAtomFoundation#192)

rsyncclient periodically flush meta table

* change rsync response (OpenAtomFoundation#190)

* change rsync response

* add debug log for test

* fix rsync client/server bugs

* fix bugs

* add debug log for test

* fix bugs

* fix bugs

* fix bugs

* rix rsync bugs (OpenAtomFoundation#194)

* fix pika rsync bug

* fix bugs

* fix bugs

* fix bugs 1

* fix bugs

* fix rsync bugs (OpenAtomFoundation#195)

* add debug log for test

* fix rsync client/server bugs

* fix bugs

* add debug log for test

* fix bugs

* fix bugs

* fix bugs

* fix bugs

* fix bugs

* fix bugs 1

* fix bugs

---------

Co-authored-by: wangshaoyi <[email protected]>

* remove unused code

* remove unused code

* remove unused code

* remove unused code

* add copyright

* fix by review comments (OpenAtomFoundation#213)

Co-authored-by: wangshaoyi <[email protected]>

* fix by review comments (OpenAtomFoundation#214)

* fix by review comments
Co-authored-by: wangshaoyi <[email protected]>

* fix by review comments (OpenAtomFoundation#216)

* fix by review comments
---------

Co-authored-by: wangshaoyi <[email protected]>

* Optimize rsync wangsy (OpenAtomFoundation#217)

* fix by review comments

Co-authored-by: wangshaoyi <[email protected]>

* fix by review comments (OpenAtomFoundation#218)

* fix by review comments
---------

Co-authored-by: wangshaoyi <[email protected]>

---------

Co-authored-by: wangshaoyi <[email protected]>
Co-authored-by: Yuecai Liu <[email protected]>
Co-authored-by: chejinge <[email protected]>
Co-authored-by: luky116 <[email protected]>
cheniujh pushed a commit to cheniujh/pika that referenced this issue Sep 24, 2024
…ess (OpenAtomFoundation#1805)

* define rsync related header file and proto

* feat:add throttle (OpenAtomFoundation#167)

* add_throttle

* feat: implement rsync network tansform (OpenAtomFoundation#169)

implement rsync network transfer

Co-authored-by: wangshaoyi <[email protected]>

* fix action (OpenAtomFoundation#171)

* fix action

* fix

* feat: add load local meta file (OpenAtomFoundation#175)

* add load meta file

* [feat] add rsync client/server code (OpenAtomFoundation#177)

* implement rsync network transfer

* add rsyncclient to syncslaveslot (OpenAtomFoundation#182)

add rsyncclient to syncslaveslot

* feat: add read meta file and data (OpenAtomFoundation#179)

* add read meta file and data

* fix compile error (OpenAtomFoundation#183)

* fix bug

* add rsyncclient to syncslaveslot

* fix compile error

* fix compile error

---------

Co-authored-by: wangshaoyi <[email protected]>

* fix compile error (OpenAtomFoundation#184)

* fix bug

* optimize: add_throttle (OpenAtomFoundation#189)

optimize throttle

* rsyncclient periodically flush meta table (OpenAtomFoundation#192)

rsyncclient periodically flush meta table

* change rsync response (OpenAtomFoundation#190)

* change rsync response

* add debug log for test

* fix rsync client/server bugs

* fix bugs

* add debug log for test

* fix bugs

* fix bugs

* fix bugs

* rix rsync bugs (OpenAtomFoundation#194)

* fix pika rsync bug

* fix bugs

* fix bugs

* fix bugs 1

* fix bugs

* fix rsync bugs (OpenAtomFoundation#195)

* add debug log for test

* fix rsync client/server bugs

* fix bugs

* add debug log for test

* fix bugs

* fix bugs

* fix bugs

* fix bugs

* fix bugs

* fix bugs 1

* fix bugs

---------

Co-authored-by: wangshaoyi <[email protected]>

* remove unused code

* remove unused code

* remove unused code

* remove unused code

* add copyright

* fix by review comments (OpenAtomFoundation#213)

Co-authored-by: wangshaoyi <[email protected]>

* fix by review comments (OpenAtomFoundation#214)

* fix by review comments
Co-authored-by: wangshaoyi <[email protected]>

* fix by review comments (OpenAtomFoundation#216)

* fix by review comments
---------

Co-authored-by: wangshaoyi <[email protected]>

* Optimize rsync wangsy (OpenAtomFoundation#217)

* fix by review comments

Co-authored-by: wangshaoyi <[email protected]>

* fix by review comments (OpenAtomFoundation#218)

* fix by review comments
---------

Co-authored-by: wangshaoyi <[email protected]>

---------

Co-authored-by: wangshaoyi <[email protected]>
Co-authored-by: Yuecai Liu <[email protected]>
Co-authored-by: chejinge <[email protected]>
Co-authored-by: luky116 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants