20 ceph rgw index 过大,到底在什么情况下,会有问题?

bucket 五百万数据,index shard = 8。 老是会出现 slows request,导致系统变慢。现在在想解决方案。

想弄明白,到底index为什么会成为系统瓶颈?原理是什么?有流程图最好!

请先 登录 后评论

最佳答案 2018-07-05 09:13

大致是这样,500万个对象在一个buck里,每个buck分8个shard,那就是500万个对象,落在8个shard里。对象的并发读写操作,需要读写这个8个shard中的一个。对osd来说,shard也就是一个object。

对于一个给定的shard object:1. 读操作是互斥的(因为pglock);2. 写操作在PG阶段写是互斥的(因为pglock),进入FileStore之后就可以并发(也不是完全并发,因为需要拿到pg上的sequencer的lock); 3. 读写大多数阶段也都是互斥的:PG阶段互斥(因为pglock); 写操作获取ondisk-writelock,进入FileStore,然后放弃pglock。这时候读操作可以进入PG阶段,但是也下不去,因为它无法获取ondisk-writelock(需要等到写操作释放ondisk-writelock)。


读的过程:    pg lock  -------->   ondisk read lock -------> sync read FileStore   ------> ondisk read unlock   -------> pg unlock;

写的过程:    pg lock ---------->  ondisk write lock -------> async write Filestore   ------> pg unlock

                                                                                          |

                                                                                          |

                                                                                          +------> data written into page cache  ---> ondisk write unlock; 


把那个shard数设置大点,应该就会好了。但是list操作就会比较慢。 我记得代码里注释说,不要超过1000(不确定了,应该是“千”)

请先 登录 后评论

其它 1 个回答

bruins

之前我们使用的  rgw_override_bucket_index_max_shards 的值为 20,你可以测试下。

bucket 500万数据不算多,建议在测试时候,抓取下index pool里的osd的op处理情况,看看在哪个地方费时较多。

可以参考这篇文章打开 ceph osd op tracker:http://www.yangguanjun.com/2017/05/23/Ceph-osd_enable_op_tracker/


请先 登录 后评论
  • 3 关注
  • 0 收藏,602 浏览
  • 文强 提出于 2018-07-03 14:39

相似问题