dw做游戏网站代码wordpress性能优化
大集群
大集群主要问题有 b+tree重平衡和分解过程中超过20Gi的性能瓶颈，是O（n）复杂度，启动耗时增大，放大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（重启后可恢复），snapshot（raftLog默认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-count=100000，默认是1000，触发raftLog到磁盘的已提交提案数
--heartbeat-interval=1000，默认是100ms，心跳间隔
--election-timeout=5000，默认是1000ms，选举超时
备注
etcd的键值被删除或更新时，旧的键值对不会被立即删除而是被标记为无效。compact能够清理被标记为无效的键值对，从而重复利用，但不会释放给系统；defrag会清理数据存储的碎片并释放给系统。kube-apiserver设置了--etcd-compaction-interval=5m0s，每5分钟清理一次
fsync函数会同步内存中所有已修改的文件数据到储存设备。
随机IO与顺序IO
当读取磁盘block时，要经历寻道，旋转延迟，传输三个步骤才能读取完这个block的数据。而对于下一个block访问它会同样经历寻道、旋转、延时,传输才能读取完这个block的数据, 这种方式的IO叫做随机IO。
但是如果下一个block的起始扇区刚好在上一个block的后面，就不需要寻道、旋转，直接传输即可，这种就叫顺序IO。
并发读特性的核心原理是创建读事务对象时，它会全量拷贝当前写事务未提交的 buffer 数据，并发的读写事务不再阻塞在一个 buffer 资源锁上，实现了全并发读。最重要的是，写事务也不再因为 expensive read request 长时间阻塞，有效的降低了写请求的延时。