vinchen
vinchen
你好，提供下当前配置和硬件配置？ 这个性能不应该这么差 另外，发现平均排队的时间达到了242ms，这个排队时间是哪个指标？ 4000QPS都是什么操作？
你好，试下这个配置，看是否有改善 ``` cluster-enabled: yes daemon on loglvevel notice rocks.blockcachemb 307200 executorThreadNum 48 truncateBinlogNum 100000 binlogDelRange 50000 maxBinlogKeepNum 20 minBinlogKeepSec 86400 jeprof-auto-dump false netiothreadnum 8 deletefilesinrange-for-binlog true ``` 另外，当前的客户端连接有多少
1. 300GB的block cache满了，实际数据量有多少？ 如果有300GB以上的物理内存，可以考虑开启这个参数 `rocks.cache_index_and_filter_blocks 1` 表示将rocksdb的索引和bloom filter常驻内存，内存够大可以打开 2. 4000QPS主要是SETEX命令 请问是不是这个有大量key不存在的插入 例如，`setnx a b`，key a是不存在的。 如果存在，可以增加配置 `rocks.optimize_filters_for_hits 0` 表示最后一层的bloom filter是否开启
你好，挂掉是因为oom还是core了 如果core了，提供下coredump的堆栈
如果可以，请提供一下这个操作完整序列，并且重现这个问题的方式 另外，也需要提供完整配置，以及硬件CPU和内存信息 如果是OOM，可以查看系统日志来确认
你好，分析慢查询的方式 1. 判断当时系统负载 2. 判断慢查询的时间戳是否集中，慢查询的比例如何 3. 分析rocksdb日志，搜索compaction相关日志，看下在慢查询对应时间是否存在大量compaction 4. 通过monitor分析是否存在大key 另外，尝试修改这个参数 binlogdelrange 10000
tendis正常重启拉起速度是很快的 如果是异常重启，有可能需要进入rocksdb的recovery模式，建议看下rocksdb相关文档 https://github.com/facebook/rocksdb/wiki/WAL-Recovery-Modes 会有相关日志