网站分析设计做的项目的过程,wordpress博客可以下载官方的模板,做果蔬行业的网站,网站在线咨询模块大集群
大集群主要问题有 btree重平衡和分解过程中超过20Gi的性能瓶颈#xff0c;是O#xff08;n#xff09;复杂度#xff0c;启动耗时增大#xff0c;放大expensive request的影响。
其中最重要的就是最大程度地减少 expensive request。
对几十万级别的对象数量来说…大集群
大集群主要问题有 btree重平衡和分解过程中超过20Gi的性能瓶颈是On复杂度启动耗时增大放大expensive request的影响。
其中最重要的就是最大程度地减少 expensive request。
对几十万级别的对象数量来说按标签还是获取所有cr等场景时很容易造成 etcd 和 kube-apiserver OOM 和丢包乃至雪崩等问题发生。 可采取措施资源按 namespace 拆分分页查Informer 机制Watch bookmark 机制利用Notify 机制实现高效的 Watch 恢复机制。 etcd 默认心跳间隔时间heartbeat-interval是 100ms 默认竞选超时时间election timeout是 1000ms 你需要根据实际部署环境、业务场景适当调优否则就很可能会频繁发生 Leader 选举切换导致服务稳定性下降 etcd proxy扩展性能可以实现 cheap/expensive read request 隔离。
etcd 是一个对磁盘 IO 性能非常敏感的存储系统磁盘 IO 性能不仅会影响 Leader 稳定性、写性能表现还会影响读性能。线性读性能会随着写性能的增加而快速下降。 etcdctl get key --rev etcd有三个磁盘存储 etcd db异步批量提交的事物数据WAL重启后可恢复snapshotraftLog默认10w条拍一次snapshot从而降低内存开销 etcd常见报错原因
当一个请求超过 300ms 时就会打印整个请求信息。
etcdserver: too many requests
任何请求提交到Raft 模块都会做Preflight Check当Raft 模块已提交的日志索引committed index比已应用到状态机的日志索引applied index超过了 5000会打印此日志。
apply request took too long
处理写请求put/txn流程 或 处理读请求 range 流程时若一个请求执行超过 100ms 时则会打印此日志。
waiting for ReadIndex response took too long, retrying
线性读时向raft模块发送readIndex请求来确保本节点状态机的已应用日志索引 (applied index) 大于等于 Leader 的已提交日志索引等待readIndex请求返回时超时超时时间500s。
ignored out-of-date read index response; local node read indexes queueing up and waiting to be in sync with leader {level:warn,ts:2023-09-13T00:00:20.135Z,caller:etcdserver/v3_server.go:817,msg:ignored out-of-date read index response; local node read indexes queueing up and waiting to be in sync with leader,sent-request-id:13287178521848115518,received-request-id:13287178521848115504} sending database snapshot to client
执行etcdctl snapshot时打印打信息。 etcd启动参数最佳实践
--snapshot-count100000默认是1000触发raftLog到磁盘的已提交提案数
--heartbeat-interval1000默认是100ms心跳间隔
--election-timeout5000默认是1000ms选举超时 备注
etcd的键值被删除或更新时旧的键值对不会被立即删除而是被标记为无效。compact能够清理被标记为无效的键值对从而重复利用但不会释放给系统defrag会清理数据存储的碎片并释放给系统。kube-apiserver设置了--etcd-compaction-interval5m0s每5分钟清理一次
fsync函数会同步内存中所有已修改的文件数据到储存设备。
随机IO与顺序IO 当读取磁盘block时要经历寻道旋转延迟传输三个步骤才能读取完这个block的数据。而对于下一个block访问它会同样经历寻道、旋转、延时,传输才能读取完这个block的数据, 这种方式的IO叫做随机IO。 但是如果下一个block的起始扇区刚好在上一个block的后面就不需要寻道、旋转直接传输即可这种就叫顺序IO。
并发读特性的核心原理是创建读事务对象时它会全量拷贝当前写事务未提交的 buffer 数据并发的读写事务不再阻塞在一个 buffer 资源锁上实现了全并发读。最重要的是写事务也不再因为 expensive read request 长时间阻塞有效的降低了写请求的延时。
