SongZhao

👍

use the order below to avoid this problem :-) 1. update the new membership config to old cluster 2. start the new server

多谢反馈，pika这里除了连接数上限之外没有其他限制，你可以先排查一下： 1. 出错时段客户端报什么错，超时？ 2. 如果是超时错误，看下无响应时段pika的慢日志，猜测那个时候可能是你们有在集中执行耗时比较多的请求，导致其他请求无法响应 另外，你们用的pika的版本是多少呢？

你们的连接数及QPS都不大，不应该出现这样的问题，我看图里的高峰时段是在13:20到13:25之间，这段时间的慢日志也正常吗？如果确认排除慢请求造成的阻塞，那请再确认一下： 1. 服务器在问题时段的负载信息：CPU，内存及磁盘占用，磁盘及网络io 2. 平时状态下客户端都有什么请求？高峰状态下多出来的100多客户端在做什么请求？你们有zset的删除或过期操作吗，是否频繁？ 3. 问题时段出错的客户端是连接超时还是读写超时？ 4. 问题时段的持续时间大概多久呢？如果稳定复现，你可以在出问题时通过htop或strace来看下当时pika的线程状况，是否有卡在什么调用上之类的 辛苦啦^^

嗯，应该是zrange请求过大导致线程卡死； 1. 每条命令执行完如果满足刷慢日志的条件应该是会写到慢日志文件中的，你说的慢日志中没有有两个原因：1) 那条特别慢的命令直到关闭服务时始终没有执行完；2) 可能刷到文件中了你没有找到。另外像zrange这种读命令是不会写到binlog中，只有写命令才会写binlog 2. 如果zset有较频繁并且大量的过期操作（已过期），这样的情况会稍微影响zrange的执行效率，如果你们的过期操作很多并且已经有大量的元素已经过期，推荐在负载低峰时手动执行compact命令，这样可以提高zrange的执行速度 3. pika是基于kv的接口来实现的zset和hash结构，所以zrange，hkeys和hgetall的复杂度均为O(N)，不过不同于redis的内存操作，pikaO(N)的每次操作是对磁盘进行读写（当然由于cache，也不是全部进行磁读写磁盘），这三个操作的性能均低于redis 4. 在数据量较大的情况下不推荐直接使用keys，hkeys，hgetall等获取全量数据的接口，可以使用scan，hscan加count来替代，将一次请求切分为多次来执行

这个是由rocksdb支持的，通过iterator可以按照字典序将key从小到大遍历出来，所以nemo只需要将存在rocksdb的key按一定方式拼接组织（[看这里](https://github.com/Qihoo360/pika/wiki/pika-nemo引擎数据存储格式)），就可以完成相关排序了

在nemo层面是O(m)，不过真正在rocksdb的层面还是O(N)，具体的原因你可以看下nemo和rocksdb的实现

1. TTL means "Time To Live" 2. nemo-rocksdb is just a LIBRARY, not a server implementation, you can treat it as a specific rocksdb which is supporting TTL

引擎对member的大小没有限制，不过协议解析模块默认循环使用2M的buffer，所以说如果在协议包中有单个字段大于2M，服务端会直接关闭连接停止解析，这个你们可以再pink的代码里根据自己的需要去调整，不过你们单个字段就2M是有些大了。。。

不会阻塞请求，是rocksdb的特性，不过在数据量很大并且执行info keyspace时不推荐compact