wangshao1

Try this ``` go router.Use(cors.New(cors.Config{ AllowMethods: []string{"GET", "POST", "OPTIONS", "PUT"}, AllowHeaders: []string{"Origin", "Content-Length", "Content-Type", "User-Agent", "Referrer", "Host", "Token"}, ExposeHeaders: []string{"Content-Length"}, AllowCredentials: true, AllowAllOrigins: false, AllowOriginFunc: func(origin string) bool { return...

pika server解析出完整命令之后交由工作线程处理，然后会del对应connfd的读写事件，所以我理解在上一个请求处理完成向client回包之前，不会在收包，所以不会出现同一个连接上多个请求同时被工作线程池中的多个线程处理的情况。 但pika server不能保证多条conn的串行执行，所以可能跟客户端实现有关。即：多线程发起pipeline请求，最终每个线程的pipeline可能是由不同连接发送出去的。github.com/redis/go-redis/v9这里的客户端实现看起来就是这种情况。

我感觉，你的这个内存使用包含了pagecache，大部分内存都是pagecache占用的，下次在出现这种情况时，清空下pagecache看内存有没有掉下来： sudo echo 3 >> /proc/sys/vm/drop_caches @chenbt-hz cc @AlexStocks

还有，看起来你们开了SWAP？，线上建议把swap关了。

我这边测试的场景是： 48核物理机，nvme ssd盘，部署两个独立的pika节点，每个节点db目录下数据为400GB+，压测客户端与pika所在物理机ping延迟0.0x ms级别。部署一个实例或者部署两个实例，TP9999都没有超过10ms。 如果这个稳定在你那边是稳定复现的话，咱们可以再对比一下测试过程中一些系统指标的差异。

有一个max-total-wal-size的参数用来设置单个rocksdb的wal的最大值。 使用复杂数据类型，元信息和data信息存放在不同Columnfamily，元信息数据量小，可能一直没有flush，导致的wal就会攒的比较多。 后续pika这边需要支持并发地open rocksdb，现在顺序open时间也长。

16:22 ~ 17:37 这个区间内，pika这段时间没有日志输出，每个rocksdb也没有日志输出吗？我总感觉应该还是在rocksdb层面。

这个是异步读rocksdb里的数据到rediscache里，没有数据需要读的时候应该就是wait在条件变量上。 你现场还在的话，可以看下启动线程阻塞在啥地方了。 rocksdb的日志，帮忙grep一下 Recovering from manifest和Recovered from manifest这两条日志打印的时间。

这个是为了规避4.0.0版本bug写入的脏数据而加的洗数据策略的执行时间过长导致的，洗数据时间与string数据量相关。关联pr： https://github.com/OpenAtomFoundation/pikiwidb/pull/2888 临时的解决办法是配置文件里把wash_data设置为false，不过需要确认之前调用过incr相关接口。

> 3.5.5 底层数据格式跟3.3.6是一样的吗，可以原地升级吗 可以原地升级，如果是主从部署的话，需要一块升级，而且升级之后没办法在回滚到3.3.6. 具体原因是： 1. 3.5与之前的版本主从全量同步没有办法做，因为3.5之前的主从全量数据同步是用的linux的rsync工具，3.5版本的主从全量同步用是pika自己实现的，协议不兼容。 2. 3.5之前的版本用的rocksdb跟3.5版本不一样，因为rocksdb的不同版本的兼容性，导致3.5之前版本可以升级到3.5，但是3.5没有办法回滚到之前的3.3