本文介绍: c. 指数退避重试机制能保证摄入的完整性以及因集群瞬时不可用导致的大面积写入失败，opensearch–py包中有如下摄入函数, 如果并发客户端过多，可能会导致CPU利用率一直位于100%，在max_retries的重试次数内，每次会等待 initial_backoff * (attampt_idx ** 2)的时间，通过设定一个较大的initial_backoff等待时间，能避免在客户端并发数偏大的情况下出现大面积429错误。d. 写入完成后，建议查询文档的去重数量，确保写入的完整性。
以往 OpenSearch 摄入时的一些最佳实践中并不包含 knn 的情况，所以在 knn 索引存在的情况，不能完全参照之前的结论，通过以上三种不同的实验方式，在多次实验的过程中，本文得到了以下的一些实践经验和结论，供参考：
a. CPU 利用率和参数 ef_construction 与 m 明显正相关，在实验中使用较大的 ef_construction 和 m 时，CPU 很容易达到 100%。实验中，在其他参数相同的情况下，ef_construction 为 512 时，CPU 利用率会长期保持在 100%，改为 2 时，利用率基本在 20% 以下，峰值不超过 30%。
b. 客户端并行数量与 OpenSearch 的摄入速度和负载成正相关，但并不是线性相关。多客户端能提高摄入速度，但是客户端数量过多，可能会导致大量的(429, ‘429 Too Many Requests /_bulk’)和(503, “No server available to handle the request..”)等错误。
c. 指数退避重试机制能保证摄入的完整性以及因集群瞬时不可用导致的大面积写入失败，opensearch–py包中有如下摄入函数, 如果并发客户端过多，可能会导致CPU利用率一直位于100%，在max_retries的重试次数内，每次会等待 initial_backoff * (attampt_idx ** 2)的时间，通过设定一个较大的initial_backoff等待时间，能避免在客户端并发数偏大的情况下出现大面积429错误。另外客户端数也不能过大，否则也会更容易出现大量的503相关错误。对于偶发的503报错，可以利用 glue 的 retry 机制处理，保证写入的完整性。
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
