We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
我们测试环境 37w+的key,列表加载大概需要四五十秒,线上环境上亿的key,几乎没法使用,难道是把所有的key都scan,直至cursor为0才停止?
直接上图吧,加载我们线上环境的数据,等了很久最后内存溢出:
测试环境37w+的key,和 medis2 做比较,medis2 列表几乎是秒出,只获取到满足翻页数量的数据后就停止scan,除非手动点击下一页(然后在用最后一次的 cursor 去继续加载更多,非严格意义上的准确翻页),而且使用它自己的日志记录可以看得出来,类型是在滚动到视图以内之后再并行使用type命令延迟加载的,最后如果直接点击到具体的key之后 再分别使用 get 和 ttl 去获取内容以及过期时间,但是redis-pro 不知道是怎么处理的,每次列表和翻页,测试环境几乎需要 四五十秒才能出结果
The text was updated successfully, but these errors were encountered:
感谢反馈, 这应该是个bug, 目前的做法是, 如果是*,空格等全匹配时,只查出第一页, 数量使用dbsize 。 scan 的时候每页数量不是固定的, 可能会出偏差, 所以在分页时使用了递归查询。 我造一些数据试一下。
Sorry, something went wrong.
找到问题了, 用swift concurrency 重构的时候, 有个参数传错了
No branches or pull requests
我们测试环境 37w+的key,列表加载大概需要四五十秒,线上环境上亿的key,几乎没法使用,难道是把所有的key都scan,直至cursor为0才停止?
直接上图吧,加载我们线上环境的数据,等了很久最后内存溢出:
测试环境37w+的key,和 medis2 做比较,medis2 列表几乎是秒出,只获取到满足翻页数量的数据后就停止scan,除非手动点击下一页(然后在用最后一次的 cursor 去继续加载更多,非严格意义上的准确翻页),而且使用它自己的日志记录可以看得出来,类型是在滚动到视图以内之后再并行使用type命令延迟加载的,最后如果直接点击到具体的key之后 再分别使用 get 和 ttl 去获取内容以及过期时间,但是redis-pro 不知道是怎么处理的,每次列表和翻页,测试环境几乎需要 四五十秒才能出结果
The text was updated successfully, but these errors were encountered: