先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）
正文
8，debug配置参数
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
debug_lockdep = 0/0
debug_context = 0/0
debug_crush = 0/0
debug_buffer = 0/0
debug_timer = 0/0
debug_filer = 0/0
debug_objecter = 0/0
debug_rados = 0/0
debug_rbd = 0/0
debug_journaler = 0/0
debug_objectcatcher = 0/0
debug_client = 0/0
debug_osd = 0/0
debug_optracker = 0/0
debug_objclass = 0/0
debug_filestore = 0/0
debug_journal = 0/0
debug_ms = 0/0
debug_mon = 0/0
debug_monc = 0/0
debug_tp = 0/0
debug_auth = 0/0
debug_finisher = 0/0
debug_heartbeatmap = 0/0
debug_perfcounter = 0/0
debug_asok = 0/0
debug_throttle = 0/0
debug_paxos = 0/0
debug_rgw = 0/0
|
关闭了所有的debug信息，能一定程度加快ceph集群速度，但也会丢失一些关键log，出问题的时候不好分析；
参考：
http://www.10tiao.com/html/362/201609/2654062487/1.html
9，osd op配置参数
1
2
3
4
5
6
|
osd_enable_op_tracker = false 默认值 true
osd_num_op_tracker_shard = 32 默认值 32
osd_op_threads = 10 默认值 2
osd_disk_threads = 1 默认值 1
osd_op_num_shards = 32 默认值 5
osd_op_num_threads_per_shard = 2 默认值 2
|
osd_enable_op_tracker：追踪osd op状态的配置参数，默认为true；不建议关闭，关闭后osd的 slow_request，ops_in_flight，historic_ops 无法正常统计；
1
2
3
4
|
ceph daemon /var/run/ceph/ceph-osd.0.asok dump_ops_in_flight
op_tracker tracking is not enabled now, so no ops are tracked currently, even those get stuck. Please enable “osd_enable_op_tracker”, and the tracker will start to track new ops received afterwards.
ceph daemon /var/run/ceph/ceph-osd.0.asok dump_historic_ops
op_tracker tracking is not enabled now, so no ops are tracked currently, even those get stuck. Please enable “osd_enable_op_tracker”, and the tracker will start to track new ops received afterwards.
|
打开op tracker后，若集群iops很高，osd_num_op_tracker_shard可以适当调大，因为每个shard都有个独立的mutex锁；
1
2
3
4
5
6
7
8
9
10
11
12
|
class OpTracker {
…
struct ShardedTrackingData {
Mutex ops_in_flight_lock_sharded;
xlist<TrackedOp > ops_in_flight_sharded;
explicit ShardedTrackingData(string lock_name):
ops_in_flight_lock_sharded(lock_name.c_str()) {}
};
vector<ShardedTrackingData> sharded_in_flight_list;
uint32_t num_optracker_shards;
…
};
|
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和osd_op_num_threads_per_shard：对应的thread pool为osd_op_tp，work queue为op_shardedwq；
处理的请求包括：
OpRequestRefPGSnapTrimPGScrub
调大osd_op_num_shards可以增大osd ops的处理线程数，增大并发性，提升OSD性能；
10，osd client message配置参数
1
2
|
osd_client_message_size_cap = 1048576000 默认值 5001024L1024L // client data allowed in-memory (in bytes)
osd_client_message_cap = 10000 默认值 100 // num client messages allowed in-memory
|
这个是osd端收到client messages的capacity配置，配置大的话能提升osd的处理能力，但会占用较多的系统内存；
配置建议：
服务器内存足够大的时候，适当增大这两个值
11，osd scrub配置参数
1
2
3
4
5
6
7
8
9
10
11
|
osd_scrub_begin_hour = 2 默认值 0
osd_scrub_end_hour = 6 默认值 24
// The time in seconds that scrubbing sleeps between two consecutive scrubs
osd_scrub_sleep = 2 默认值 0 // sleep between [deep]scrub ops
osd_scrub_load_threshold = 5 默认值 0.5
// chunky scrub配置的最小/最大objects数，以下是默认值
osd_scrub_chunk_min = 5
osd_scrub_chunk_max = 25
|
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全是小文件的情况，这两个值需要调大；
参考：
http://www.jianshu.com/p/ea2296e1555c
http://tracker.ceph.com/issues/19497
12，osd thread timeout配置参数
1
2
3
4
5
|
osd_op_thread_timeout = 580 默认值 15
osd_op_thread_suicide_timeout = 600 默认值 150
osd_recovery_thread_timeout = 580 默认值 30
osd_recovery_thread_suicide_timeout = 600 默认值 300
|
osd_op_thread_timeout和osd_op_thread_suicide_timeout关联的work queue为：
op_shardedwq- 关联的请求为：OpRequestRef，PGSnapTrim，PGScrubpeering_wq- 关联的请求为：osd peering
osd_recovery_thread_timeout和osd_recovery_thread_suicide_timeout关联的work queue为：
recovery_wq- 关联的请求为：PG recovery
Ceph的work queue都有个基类WorkQueue_，定义如下：
1
2
3
4
5
6
7
8
9
10
11
|
/// Pool of threads that share work submitted to multiple work queues.
class ThreadPool : public md_config_obs_t {
…
/// Basic interface to a work queue used by the worker threads.
struct WorkQueue_ {
string name;
time_t timeout_interval, suicide_interval;
WorkQueue_(string n, time_t ti, time_t sti)
: name(n), timeout_interval(ti), suicide_interval(sti)
{ }
…
|
这里的timeout_interval和suicide_interval分别对应上面所述的配置timeout和suicide_timeout；
当thread处理work queue中的一个请求时，会受到这两个timeout时间的限制：
timeout_interval- 到时间后设置m_unhealthy_workers+1suicide_interval- 到时间后调用assert，OSD进程crush
对应的处理函数为：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
bool HeartbeatMap::_check(const heartbeat_handle_d *h, const char *who, time_t now)
{
bool healthy = true;
time_t was;
was = h->timeout.read();
if (was && was < now) {
ldout(m_cct, 1) << who << " ‘" << h->name << "’"
<< " had timed out after " << h->grace << dendl;
healthy = false;
}
was = h->suicide_timeout.read();
if (was && was < now) {
ldout(m_cct, 1) << who << " ‘" << h->name << "’"
<< " had suicide timed out after " << h->suicide_grace << dendl;
assert(0 == “hit suicide timeout”);
}
return healthy;
}
|
当前仅有RGW添加了worker的perfcounter，所以也只有RGW可以通过perf dump查看total/unhealthy的worker信息：
1
2
3
|
[root@ yangguanjun]# ceph daemon /var/run/ceph/ceph-client.rgw.rgwdaemon.asok perf dump | grep worker
“total_workers”: 32,
“unhealthy_workers”: 0
|
对应的配置项为：
1
2
3
4
5
6
7
8
9
10
11
12
13
|
OPTION(rgw_num_async_rados_threads, OPT_INT, 32) // num of threads to use for async rados operations
配置建议：
*_thread_timeout：这个值配置越小越能及时发现处理慢的请求，所以不建议配置很大；特别是针对速度快的设备，建议调小该值；*_thread_suicide_timeout：这个值配置小了会导致超时后的OSD crush，所以建议调大；特别是在对应的throttle调大后，更应该调大该值；
13，fielstore op thread配置参数
filestore_op_threads = 10 默认值 2
filestore_op_thread_timeout = 580 默认值 60
filestore_op_thread_suicide_timeout = 600 默认值 180
|
filestore_op_threads：对应的thread pool为op_tp，对应的work queue为op_wq；filestore的所有请求都经过op_wq处理；
增大该参数能提升filestore的处理能力，提升filestore的性能；配合filestore的throttle一起调整；
filestore_op_thread_timeout和filestore_op_thread_suicide_timeout关联的work queue为：op_wq
配置的含义与上一节中的thread_timeout/thread_suicide_timeout保持一致；
13，filestore merge/split配置参数
1
2
|
filestore_merge_threshold = -1 默认值 10
filestore_split_multiple = 16000 默认值 2
|
这两个参数是管理filestore的目录分裂/合并的，filestore的每个目录允许的最大文件数为：
filestore_split_multiple * abs(filestore_merge_threshold) * 16
在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_*, 就放进子目录 DIR_0/DIR_C/DIR_4/DIR_A 里；
解决办法：
- 增大merge/split配置参数的值，使单个目录容纳更多的文件；
filestore_merge_threshold配置为负数；这样会提前触发目录的预分裂，避免目录在某一时间段的集中分裂，详细机制没有调研；- 创建pool时指定
expected-num-objects；这样会依据目录分裂规则，在创建pool的时候就创建分裂的子目录，避免了目录分裂对filestore性能的影响；
参考：
http://docs.ceph.com/docs/master/rados/configuration/filestore-config-ref/
http://docs.ceph.com/docs/jewel/rados/operations/pools/#create-a-pool
http://blog.csdn.net/for_tech/article/details/51251936
http://ivanjobs.github.io/page3/
14，filestore fd cache配置参数
1
2
|
filestore_fd_cache_shards = 32 默认值 16 // FD number of shards
filestore_fd_cache_size = 32768 默认值 128 // FD lru size
|
filestore的fd cache是加速访问filestore里的file的，在非一次性写入的应用场景，增大配置可以很明显的提升filestore的性能；
15，filestore sync配置参数
1
2
3
4
|
filestore_wbthrottle_enable = false 默认值 true SSD的时候建议关闭
filestore_min_sync_interval = 5 默认值 0.01 s 最小同步间隔秒数，sync fs的数据到disk，FileStore::sync_entry()
filestore_max_sync_interval = 10 默认值 5 s 最大同步间隔秒数，sync fs的数据到disk，FileStore::sync_entry()
filestore_commit_timeout = 3000 默认值 600 s FileStore::sync_entry() 里 new SyncEntryTimeout(m_filestore_commit_timeout)
|
filestore_wbthrottle_enable的配置是关于filestore writeback throttle的，即我们说的filestore处理workqueue op_wq的数据量阈值；默认值是true，开启后XFS相关的配置参数有：
1
2
3
4
5
6
|
OPTION(filestore_wbthrottle_xfs_bytes_start_flusher, OPT_U64, 41943040)
OPTION(filestore_wbthrottle_xfs_bytes_hard_limit, OPT_U64, 419430400)
OPTION(filestore_wbthrottle_xfs_ios_start_flusher, OPT_U64, 500)
OPTION(filestore_wbthrottle_xfs_ios_hard_limit, OPT_U64, 5000)
OPTION(filestore_wbthrottle_xfs_inodes_start_flusher, OPT_U64, 500)
OPTION(filestore_wbthrottle_xfs_inodes_hard_limit, OPT_U64, 5000)
|
若使用普通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配置参数
1
2
3
4
5
6
7
8
9
10
11
|
filestore_expected_throughput_bytes = 536870912 默认值 200MB /// Expected filestore throughput in B/s
filestore_expected_throughput_ops = 2500 默认值 200 /// Expected filestore throughput in ops/s
filestore_queue_max_bytes= 1048576000 默认值 100MB
filestore_queue_max_ops = 5000 默认值 50
/// Use above to inject delays intended to keep the op queue between low and high
filestore_queue_low_threshhold = 0.6 默认值 0.3
filestore_queue_high_threshhold = 0.9 默认值 0.9
filestore_queue_high_delay_multiple = 2 默认值 0 /// Filestore high delay multiple. Defaults to 0 (disabled)
filestore_queue_max_delay_multiple = 10 默认值 0 /// Filestore max delay multiple. Defaults to 0 (disabled)
|
在jewel版本里，引入了dynamic throttle，来平滑普通throttle带来的长尾效应问题；
一般在使用普通磁盘时，之前的throttle机制即可很好的工作，所以这里默认filestore_queue_high_delay_multiple和filestore_queue_max_delay_multiple都为0；
针对高速磁盘，需要在部署之前，通过小工具ceph_smalliobenchfs来测试下，获取合适的配置参数；
1
2
3
4
5
6
7
8
9
10
11
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
y multiple. Defaults to 0 (disabled)
filestore_queue_max_delay_multiple = 10 默认值 0 /// Filestore max delay multiple. Defaults to 0 (disabled)
|
在jewel版本里，引入了dynamic throttle，来平滑普通throttle带来的长尾效应问题；
一般在使用普通磁盘时，之前的throttle机制即可很好的工作，所以这里默认filestore_queue_high_delay_multiple和filestore_queue_max_delay_multiple都为0；
针对高速磁盘，需要在部署之前，通过小工具ceph_smalliobenchfs来测试下，获取合适的配置参数；
1
2
3
4
5
6
7
8
9
10
11
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-ydiktW1Q-1713120347422)]
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
扫一扫
9833
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
