- 1. 1，⼀些固定配置参数
- 2. 2，⽹络配置参数
- 3. 3，pool size配置参数
- 4. 4，认证配置参数
- 5. 5，osd down out配置参数
- 6. 6，objecter配置参数
- 7. 7，ceph rgw配置参数
- 8. 8，debug配置参数
- 9. 9，osd op配置参数
- 10. 10，osd client message配置参数
- 11. 11，osd scrub配置参数
- 12. 12，osd thread timeout配置参数
- 13. 13，filestore merge/split配置参数
- 14. 14，filestore fd cache配置参数
- 15. 15，filestore sync配置参数
- 16. 16，filestore throttle配置参数
- 17. 17，filestore finisher threads配置参数
- 18. 18，journal配置参数
- 19. 19，rbd cache配置参数
Posted on 2017-05-15 | In [c]{.ul} [eph]{.ul} | | 4099
[概]{.ul} [述 ]{.ul}
Ceph的配置参数很多，从⽹上也能搜索到⼀⼤批的调优参数，但这些参数为什么这么设置？设置为这样是否合理？解释的并不多
本⽂从当前我们的ceph.conf⽂件⼊⼿，解释其中的每⼀项配置，做为以后参数调优和新⼈学习的依据；
1，⼀些固定配置参数
以上通常是通过ceph-deploy⽣成的，都是ceph monitor相关的参数，不⽤修改；
2，⽹络配置参数
public network：monitor与osd，client与monitor，client与osd通信的⽹络，最好配置为带宽较⾼的万兆⽹络；
cluster network：OSD之间通信的⽹络，⼀般配置为带宽较⾼的万兆⽹络；
参考：
[ttp://docs.ceph.com/docs/master/rados/configuration/network-config-ref/]{.ul}
3，pool size配置参数
这两个是创建ceph pool的时候的默认size参数，⼀般配置为3和1，3副本能⾜够保证数据的可靠性；
4，认证配置参数
以上是Ceph authentication的配置参数，默认值为开启ceph认证；
在内部使⽤的ceph集群中⼀般配置为none，即不使⽤认证，这样能适当加快ceph集群访问速度；
5，osd down out配置参数
mon_osd_down_out_interval ：ceph标记⼀个osd为down and out的最⼤时间间隔mon_osd_min_down_reporters ：mon标记⼀个osd为down的最⼩reporters个数（报告该osd为down的其他osd为⼀个reporter）
mon_osd_report_timeout ：mon标记⼀个osd为down的最⻓等待时间
osd_heartbeat_interval ：osd发送heartbeat给其他osd的间隔时间（同⼀PG之间的osd才会有
heartbeat）
osd_heartbeat_grace ：osd报告其他osd为down的最⼤时间间隔，grace调⼤，也有副作⽤，如果某个osd异常退出，等待其他osd上报的时间必须为grace，在这段时间段内，这个osd负责的pg的io会hang住，所以尽量不要将grace调的太⼤。
基于实际情况合理配置上述参数，能减少或及时发现osd变为down（降低IO hang住的时间和概率）， 延⻓osd变为down and out的时间（防⽌⽹络抖动造成的数据recovery）；
参考：
[h]{.ul} [ttp://docs.ceph.com/docs/master/rados/configuration/mon-osd-interaction/]{.ul} [h]{.ul} [ttp://blog.wjin.org/posts/ceph-osd-heartbeat.html]{.ul}
6，objecter配置参数
osd client端objecter的throttle配置，它的配置会影响librbd，RGW端的性能；
配置建议：
调⼤这两个值
7，ceph rgw配置参数
rgw_frontends ：rgw的前端配置，⼀般配置为使⽤轻量级的civetweb；prot为访问rgw的端⼝，根据实际情况配置；num_threads为civetweb的线程数；
rgw_thread_pool_size ：rgw前端web的线程数，与rgw_frontends中的num_threads含义⼀致，但
num_threads 优 于 rgw_thread_pool_size 的 配 置 ， 两 个 只 需 要 配 置 ⼀ 个 即 可 ； rgw_override_bucket_index_max_shards ：rgw bucket index object的最⼤shards数，增⼤这个值能减少bucket index object的访问时间，但也会加⼤bucket的ls时间；
rgw_max_chunk_size ：rgw最⼤chunk size，针对⼤⽂件的对象存储场景可以把这个值调⼤；
rgw_cache_lru_size ：rgw的lru cache size，对于读较多的应⽤场景，调⼤这个值能加快rgw的响应速度；
rgw_bucket_default_quota_max_objects ：配合该参数限制⼀个bucket的最⼤objects个数；
参考：
[h]{.ul} [ttp://docs.ceph.com/docs/jewel/install/install-ceph-gateway/]{.ul}
[h]{.ul} [ttp://ceph-users.ceph.narkive.com/mdB90g7R/rgw-increase-the-first-chunk-size]{.ul} [h]{.ul} [ttps://access.redhat.com/solutions/2122231]{.ul}
8，debug配置参数
关闭了所有的debug信息，能⼀定程度加快ceph集群速度，但也会丢失⼀些关键log，出问题的时候不好分析；
参考：
[h]{.ul} [ttp://www.10tiao.com/html/362/201609/2654062487/1.html]{.ul}
9，osd op配置参数
osd_enable_op_tracker ：追踪osd op状态的配置参数，默认为true；不建议关闭，关闭后osd的slow_request，ops_in_flight，historic_ops ⽆法正常统计；
打开op tracker后，若集群iops很⾼， osd_num_op_tracker_shard 可以适当调⼤，因为每个shard都有个独⽴的mutex锁；
osd_op_threads ：对应的work queue有peering_wq （osd peering请求），
recovery_gen_wq （PG recovery请求）；
osd_disk_threads ：对应的work queue为 remove_wq （PG remove请求）；
[osd_op_num_shards]{.ul} 和osd_op_num_threads_per_shard ：对应的thread pool为osd_op_tp ，work queue为op_shardedwq ；
处理的请求包括：
1.
2.
3.
调⼤osd_op_num_shards 可以增⼤osd ops的处理线程数，增⼤并发性，提升OSD性能；
10，osd client message配置参数
这个是osd端收到client messages的capacity配置，配置⼤的话能提升osd的处理能⼒，但会占⽤较多的系统内存；
配置建议：
服务器内存⾜够⼤的时候，适当增⼤这两个值
11，osd scrub配置参数
Ceph osd scrub是保证ceph数据⼀致性的机制，scrub以PG为单位，但每次scrub回获取PG lock，所以它可能会影响PG正常的IO；
Ceph后来引⼊了chunky的scrub模式，每次scrub只会选取PG的⼀部分objects，完成后释放PG lock， 并把下⼀次的PG scrub加⼊队列；这样能很好的减少PG scrub时候占⽤PG lock的时间，避免过多影响PG正常的IO；
同理，引⼊的osd_scrub_sleep 参数会让线程在每次scrub前释放PG lock，然后睡眠⼀段时间，也能很好的减少scrub对PG正常IO的影响；
配置建议：
osd_scrub_begin_hour 和osd_scrub_end_hour ：OSD Scrub的开始结束时间，根据具体业务指定；
osd_scrub_sleep ：osd在每次执⾏scrub时的睡眠时间；有个bug跟这个配置有关，建议关闭；
osd_scrub_load_threshold ：osd开启scrub的系统load阈值，根据系统的load average值配置该参数；
osd_scrub_chunk_min 和osd_scrub_chunk_max ：根据PG中object的个数配置；针对RGW全是
⼩⽂件的情况，这两个值需要调⼤；
参考：
[h]{.ul} [ttp://www.jianshu.com/p/ea2296e1555c]{.ul} [h]{.ul} [ttp://tracker.ceph.com/issues/19497]{.ul}
12，osd thread timeout配置参数
osd_op_thread_timeout 和osd_op_thread_suicide_timeout 关联的work queue为：
- 关联的请求为： OpRequestRef ， PGSnapTrim ， PGScrub
- 关联的请求为：osd peering
osd_recovery_thread_timeout 和osd_recovery_thread_suicide_timeout 关联的work queue
为：
- 关联的请求为：PG recovery
Ceph的work queue都有个基类WorkQueue_ ，定义如下：
这⾥的timeout_interval 和suicide_interval 分别对应上⾯所述的配置timeout 和
当thread处理work queue中的⼀个请求时，会受到这两个timeout时间的限制：
到时间后设置m_unhealthy_workers+1
到时间后调⽤assert，OSD进程crush
对应的处理函数为：
当前仅有RGW添加了worker的perfcounter，所以也只有RGW可以通过perf dump查看total/unhealthy
的worker信息：
对应的配置项为：
filestore_op_threads ：对应的thread pool为op_tp ，对应的work queue为op_wq ；filestore的所有请求都经过op_wq处理；
增⼤该参数能提升filestore的处理能⼒，提升filestore的性能；配合filestore的throttle⼀起调整；
配置的含义与上⼀节中的[thread_timeout/thread_suicide_timeout]{.ul} 保持⼀致；
13，filestore merge/split配置参数
这两个参数是管理filestore的⽬录分裂/合并的，filestore的每个⽬录允许的最⼤⽂件数为：
在RGW的⼩⽂件应⽤场景，会很容易达到默认配置的⽂件数（320），若在写的过程中触发了filestore 的分裂，则会⾮常影响filestore的性能；
每次filestore的⽬录分裂，会依据如下规则分裂为多层⽬录，最底层16个⼦⽬录：
例如PG 31.4C0, hash结尾是4C0，若该⽬录分裂，会分裂为 DIR_0/DIR_C/DIR_4/{DIR_0, DIR_F} ；
原始⽬录下的object会根据规则放到不同的⼦⽬录⾥，object的名称格式为: * head_xxxxX4C0_* ，分裂时候X是⼏，就放进⼦⽬录DIR_X⾥。⽐如object： * head_xxxxA4C0_* , 就放进⼦⽬录
⾥；
解决办法：
增⼤merge/split配置参数的值，使单个⽬录容纳更多的⽂件；
filestore_merge_threshold 配置为负数；这样会提前触发⽬录的预分裂，避免⽬录在某⼀时间段的集中分裂，详细机制没有调研；
创建pool时指定expected-num-objects ；这样会依据⽬录分裂规则，在创建pool的时候就创建分
裂的⼦⽬录，避免了⽬录分裂对filestore性能的影响；
参考：
[h]{.ul} [ttp://docs.ceph.com/docs/master/rados/configuration/filestore-config-ref/]{.ul} [h]{.ul} [ttp://docs.ceph.com/docs/jewel/rados/operations/pools/#create-a-pool]{.ul}
[h]{.ul} [ttp://blog.csdn.net/for_tech/article/details/51251936]{.ul} [h]{.ul} [ttp://ivanjobs.github.io/page3/]{.ul}
14，filestore fd cache配置参数
filestore的fd cache是加速访问filestore⾥的file的，在⾮⼀次性写⼊的应⽤场景，增⼤配置可以很明显的提升filestore的性能；
15，filestore sync配置参数
filestore_wbthrottle_enable 的配置是关于filestore writeback throttle的，即我们说的filestore处理workqueue op_wq 的数据量阈值；默认值是true，开启后XFS相关的配置参数有：
若使⽤普通HDD，可以保持其为true；针对SSD，建议将其关闭，不开启writeback throttle；
filestore_min_sync_interval 和 filestore_max_sync_interval 是 配 置 filestore flush outstanding IO到disk的时间间隔的；增⼤配置可以让系统做尽可能多的IO merge，减少filestore写磁盘的压⼒，但也会增⼤page cache占⽤内存的开销，增⼤数据丢失的可能性；
filestore_commit_timeout 是配置filestore sync entry到disk的超时时间，在filestore压⼒很⼤时， 调⼤这个值能尽量避免IO超时导致OSD crush；
16，filestore throttle配置参数
在jewel版本⾥，引⼊了dynamic throttle，来平滑普通throttle带来的⻓尾效应问题；
⼀般在使⽤普通磁盘时，之前的throttle机制即可很好的⼯作，所以这⾥默认
filestore_queue_high_delay_multiple 和filestore_queue_max_delay_multiple 都为0；
针对⾼速磁盘，需要在部署之前，通过⼩⼯具ceph_smalliobenchfs 来测试下，获取合适的配置参数；
参考：
[h]{.ul} [ttp://docs.ceph.com/docs/jewel/dev/osd_internals/osd_throttles/]{.ul} [h]{.ul} [ttp://blog.wjin.org/posts/ceph-dynamic-throttle.html]{.ul}
[h]{.ul} [ttps://github.com/ceph/ceph/blob/master/src/doc/dynamic-throttle.txt]{.ul} [C]{.ul} [eph BackoffThrottle分析]{.ul}
17，filestore finisher threads配置参数
这两个参数定义filestore commit/apply的finisher处理线程数，默认都为1，任何IO commit/apply完成后，都需要经过对应的ondisk/apply finisher thread处理；
在使⽤普通HDD时，磁盘性能是瓶颈，单个finisher thread就能处理好；
但在使⽤⾼速磁盘的时候，IO完成⽐较快，单个finisher thread不能处理这么多的IO commit/apply reply，它会成为瓶颈；所以在jewel版本⾥引⼊了finisher thread pool的配置，这⾥⼀般配置为2即可；
18，journal配置参数
journal_max_write_bytes 和journal_max_write_entries 是journal⼀次write的数据量和entries 限制；
针对SSD分区做journal的情况，这两个值要增⼤，这样能增⼤journal的吞吐量；
journal_throttle_high_multiple 和journal_throttle_max_multiple 是JournalThrottle 的配置参数， JournalThrottle 是BackoffThrottle 的封装类，所以JournalThrottle 与我们在filestore throttle介绍的dynamic throttle⼯作原理⼀样；
从上述代码中看出相关的配置参数有：
19，rbd cache配置参数
rbd_cache_size ：client端每个rbd image的cache size，不需要太⼤，可以调整为64M，不然会⽐较占client端内存；
参照默认值，根据rbd_cache_size 的⼤⼩调整rbd_cache_max_dirty 和
rbd_cache_max_dirty ：在writeback模式下cache的最⼤bytes数，默认是24MB；当该值为0 时，表示使⽤writethrough模式；
rbd_cache_target_dirty ：在writeback模式下cache向ceph集群写⼊的bytes阀值，默认
16MB；注意该值⼀定要⼩于rbd_cache_max_dirty 值
rbd_cache_writethrough_until_flush ：在内核触发flush cache到ceph集群前rbd cache⼀直是writethrough模式，直到flush后rbd cache变成writeback模式；
rbd_cache_max_dirty_age ：标记OSDC端ObjectCacher中entry在cache中的最⻓时间；
