为啥etcd社区建议db大小不超过8G

Posted 2023-04-08

参考技术A db大小会对那些方面造成影响:

treeIndex模块维护了用户key与boltdb key的映射关系,boltdb的key、value有包含了构建treeIndex的所需的数据,etcd启动的时候,会启动不同角色的
goroutine并完成treeIndex构建。

遍历boltdb获取所有key-value的数据,并将其反序列化成etcd的mvccpb.KeyValue结构。核心原理是基于etcd存储在boltdb中的key数据有序性,按版本号
从1开始批量遍历,每次查询1000条key-value记录,直到查询数据为空。

从主goroutine获取mvccpb.KeyValue数据,基于key、版本号、是否带删除表示等信息,构建keyIndex对象,插入到treeIndex模块的B-tree中。

etcd启动时只有一个构建treeIndex的goroutine。

etcd启动时,调用boltdb Open API的时候,设置了mmap的MAP_POPULATE flag,告诉内核预读文件,将db文件内容全部从磁盘加载到物理内存中
(通过mmap机制将db文件映射到内存中)。如果节点内存小于treeIndex内存之和,会触发缺页中断,导致读延时抖动、QPS下降。

boltdb事务提交的四个核心流程:B+ tree的重平衡、分裂,持久化dirty page、持久化freelist以及持久化meta data。

事务提交延时抖动的原因主要是在B+Tree树的重平衡和分裂过程中,需要从freeList中申请若干连续的page存储数据,或者释放空闲个的freelist。

freeList后端实现在boltdb中是array。如果db文件较大,又存在大量的碎片空闲页,很可能导致超时。同时事务提交过程中,也可能会释放若干个page给
freelist,因此需要合并到freelist的数组中,此操作时间复杂度是O(NlogN)。为了优化boltdb事务提交的性能,etcd实现了基于HashMap来管理freelist。
通过引入三个map数据结构(freemaps的key是连续的页数, value是以空闲页的起始页pgid集合,forwardmap和backmap用于释放的时候快速合并页),
将申请和释放时间复杂度降低到O(1),同时支持事务提交时,不持久化freelist,而是通过重启时扫描page重建,以提升etcd写性能、降低db大小。

那些expensive read请求会导致etcd不稳定性:

快照会影响db备份文件生成速度、Leader发送快照给Follower节点的资源开销、Follower节点通过快照重建恢复的速度。

为啥 Chrome 审核会建议我最小化 cookie 大小？

【中文标题】为啥 Chrome 审核会建议我最小化 cookie 大小？

【英文标题】：Why does Chrome audit recommend me to minimize cookie size?为什么 Chrome 审核会建议我最小化 cookie 大小？

【发布时间】：2012-04-23 17:42:58

【问题描述】：

如何最小化请求的 cookie 大小？ Chrome 似乎“警告我”我的 cookie 大小为 41B，这根本不是很多，但它警告我有什么原因吗？

这是一个 PHPSESSID cookie，我真的不知道如何最小化它。有什么想法吗？

我的请求响应本身应该已经被 Gzip 压缩了，但据我所知，无法压缩标头本身，或者是否存在？

谢谢！我只是对性能和审计有一点强迫症，它们告诉我我可以做得更好。

【问题讨论】：

好吧，那只是忽略了审计中的 cookie 大小问题，它并没有真正回答我的问题，即 Chrome 为何会警告我，以及如何不被警告。

【参考方案1】：

Chrome 审核工具错误地发出此警告。 41B 是一个小 cookie，很容易适应 1500B 的 MTU。

例如，如果您对 Google.com 运行审核，它会抱怨他们的 104B cookie。 Chrome 团队需要修复此错误警告，但您无需担心。

【讨论】：

投反对票。请告诉我们一个合适的小饼干是什么？ 1 个字节？