lrucache内存达到配置的值后，写性能明显下降，压测排队时间达到200多ms #152
Comments
|
你好，提供下当前配置和硬件配置？ 另外，发现平均排队的时间达到了242ms，这个排队时间是哪个指标？ 4000QPS都是什么操作？ |
|
当前配置: 硬件配置如下: |
|
平均排队时间用的指标 avg_commands_workpool_queue_cost(ns): 242657053 |
|
你好，试下这个配置，看是否有改善 另外，当前的客户端连接有多少 |
|
好的，谢谢。 |
|
你好，试了下这个配置，没啥效果。请问这样改动原理是啥？ |
|
我看rocksdb的5.14.2的里面有提到个bug修复: |
如果有300GB以上的物理内存，可以考虑开启这个参数
如果存在，可以增加配置 |
|
谢谢，我试试。 |
[feature] feature-enable-blob 方案 ( #152 ) ### MR描述 <!--- 详细描述MR的细节 --> * 增加对 RocksDB's Blob 的封装, 暂时暴露下面几个参数: enable_blob_files (false) min_blob_size (2048) enable_blob_garbage_collection (true) ### 修改不合理的用法 1) 事务的 Lock 的开销 PessimisticTransaction PessimisticTransaction::TryLock 1.83% PessimisticTransaction::Clear() PointLockManager::UnLock 1.37% TransactionOptions::skip_concurrency_control 设置为 true, 跳过 PessimisticTransaction 的加锁和解锁行为。 2) Binlog Options 目前前两层没有开启压缩, 后面的层开启压缩。 目前在 开启 level_compaction_dynamic_level_bytes 的情况下， 假设有三层: L0 L5 L6。 从 L5 -> L6 原本 SST 不重叠, 直接 Move 即可, 但是由于 L5 L6 压缩类型不同, 依然需要 Compaction 重新生成一次 SST 文件。 #### 优化方案 * 拆分 Options 将 RocksKVStore::options() binlogColumnOptions 进行分开 ? dataColumnOptions binlogColumnOptions * 关闭 并发控制 TransactionOptions::skipConcurrencyControl 参数 默认为 false 在配置事物类型为pecTxn的情况下，skipConcurrencyControl可以配true 在配置事物类型为writeBatch的情况下，skipConcurrencyControl则必须为false #### 优化效果 上述两个 综合起来优化效果如下所示: 常见命令测试，命令列表为：set,get 全过程监控http://monitor.gcs.ied.com/d/OBmBNI2Gz/tendisx-k8s?orgId=1&var-gcs_app=sf&var-gcs_cluster=cd240r6221test&from=1630563478000&to=1630574148000 测试命令(3个): ./memtier_benchmark -c 50 -t 20 --test-time=7200 --pipeline=1 --distinct-client-seed --randomize --data-size=128 --random-data --key-minimum=1 --key-maximum=5000000000 --command='set __key__ __data__' --key-prefix='kv_' set测试曲线：http://monitor.gcs.ied.com/d/OBmBNI2Gz/tendisx-k8s?orgId=1&var-gcs_app=sf&var-gcs_cluster=cd240r6221test&from=1630563778000&to=1630570982000 <img width="" src="/uploads/CEE1F8A3FA9B453FAF85C69CC5A4CB6F/image.png" alt="image.png" /> 测试命令(3个): ./memtier_benchmark -c 50 -t 20 --test-time=7200 --pipeline=1 --distinct-client-seed --randomize --data-size=128 --random-data --key-minimum=1 --key-maximum=5000000000 --command='get __key__' --key-prefix='kv_' get测试曲线：http://monitor.gcs.ied.com/d/OBmBNI2Gz/tendisx-k8s?orgId=1&var-gcs_app=sf&var-gcs_cluster=cd240r6221test&from=1630571283000&to=1630573848000 <img width="" src="/uploads/3D82F0F1CCF64CF9A1D7CA6A7925AE20/image.png" alt="image.png" /> **性能提升 10% , QPS 从 21.0 W -> 23.1W, 命令延迟也有一些降低。** ### 修改动机和上下文背景 <!--- 为什么需要此修改, 解决了什么问题 --> <!---如果解决了相关的#issue, 在此处进行关联(#issue, close #issue) --> #152 ### 此MR如何进行测试 ? <!--- 请描述测试MR的细节 --> <!--- 包括测试的环境以及执行的测试用例 --> <!--- 说明 change 如何影响其他部分的代码 etc. --> ### change 类型 <!---你的代码引入了何种类型的change, 在所有关联的复选框前选择"x" --> - [ ] Bug fix (修复了issue的非侵入式修改) - [ ] New feature (增加功能的非侵入式修改) - [ ] Breaking change (修复或者增加特性, 但是会造成现有行为的非预期行为) ### 清单 <!--- 查看下述选项,并进行"x"勾选 --> <!--- 如果你对所有都不确定, 请随时咨询我们 --> - [ ] 遵循项目的Code-Style - [ ] Change 需要文档的修改 - [ ] 我已经进行相关文档的修改 - [ ] 我的MR已经通过的相关流水线测试
|
100kb的value算是比较长的情况了，latency确实会有不少增加。但是你给的机型和压力情况下，通过参数的调整，P95一般也是比较容易控制在20ms内的。参数配置建议。 |
Description
LruCache占用的内存达到rocks.blockcachemb配置的值后，压测容易超时（20ms），通过info stats查看，发现平均排队的时间达到了242ms，平均执行时间达到了37ms。
tendis服务是四主四从，rocks.blockcachemb配置300G。
压测时，写多，读少。配置20ms超时，key大小64字节，值大小100kb，大概4000QPS，P95会超过20ms。
Expected Behavior
期望4000QPS，P95不超过20ms
Current Behavior
4000QPS，P95超过20ms。
Possible Solution
内存占用达到blockcachemb之后，内存一直没有变小，是否应该先落盘。
Steps to Reproduce (for bugs)
配置20ms超时，key大小64字节，值大小100kb，大概4000QPS，P95会超过20ms。
Context
Your Environment
The text was updated successfully, but these errors were encountered: