然后是预期 hashmap 是 o(1)的，这么大的 map 就需要考虑是 key 量是多少，怎么分布。
hash 方案会不会导致某个 bucket 聚集了大量的 entry 。
如果 bucket 里面 entry 太多，由于 hash 冲突用的链地址法，会退化成 o(N)，N 是 bucket 里 entry 数量。
一次性放进去那么多数据会不会导致有未完成的扩容行为，冷起性能被拖累，需不需要 warm up 。
读取是全随机还是有特定热点的，在 hashmp 的基础上再套 LRU ，同样 o(1)但是收缩常数会不会更快？

@dw2693734d
都是静态数据那完全没有线程安全问题
那用 map 方案规避 GC 的话估计得靠 Arena 分配一下内存就是了
用了 Arena 不被 GC 主要就关注一下会不会发生奇怪的内存泄露情况
现代操作系统反正内存基本上有 Swap 都是用不完的，但 Swap 是福也是祸
生产性能非预期就需要确定会不会因为 Swap 导致性能暴跌

用 bigcache ，前人总是踩过一些坑才做了这些工作。主要有这几个优势：
1. Zero GC 如果 map 有上万对象 GC 起来要命，通过 cacheShard 里 ringBuffer 避免 GC 扫对象
2. FIFO 过期策略，省的处理淘汰跟溢出的问题
3. 并发安全，给上分片读写锁

两年前 Air 16+256 84xx 入的
现在二手价格还有 7 成……
Pro 虽然是 2021 年发布的，也坚挺了很久没有下探

@eastgame 6.17 有 1599-200 错过只能再等等

Redmi 27 4K
虽然是 BOE 面板但色准过关 还给 Tpye-C
jd 618 好价 1379

反过来问，为什么互联网企业要去厦门发展？

这类问题就是 RPO 和 Perf 之间的取舍，最后就是看能不能接受 RPO>0 。如果能接受 RPO>0 丢几个数据那就没啥问题。

@huangya 刷了 hanwckf 的 ImmortalWrt ，CPU 频率没跳过……

个人两台 AX6000 日常 CPU 53 WIFI 55 的温度，其中一台跑了半年多没啥毛病，不是很担心会有问题。
MT7986A 是没有动态节能的，也就是哪怕空载也是 2.0GHz……所以看起来会觉得热。

意味着执行计划不会有问题的情况下，下层结构会带来哪些可能的问题。
如果是 InnoDB 的话，首先是 Buffer Pool 本身访问就是需要 Mutex 的，有没有可能是等锁导致的慢呢？
进一步的，如果 Buffer Pool 没有命中就需要从磁盘拖数据，磁盘 IO 导致的慢呢？
从磁盘拖回来的数据如果是有问题的，比如刷出来了个 Crash 完以后 LSN 高于 Checkpoint 的脏页，从 Redo-Log 恢复数据导致的慢呢？

HPE MS Gen8

@xinmans ML110Gen9 塔式声音不大 日常主要是硬盘的炒豆子声

2666v3 + 64G 配置带 K8S 基本没什么压力，日常 CPU 占用率约 16%，RAM 用了 50%左右……i3 8100 确实不适合带 K3S

@lcy630409 各家都在给携转 KPI 整活，但这个资费是否长期就是个问题……

还是画个图比较好理解
[drawio-1.png]( https://postimg.cc/21TGgSXq)

你给开发双份的钱让他转运维就行了

一套 OpenWRT 不行就两套……主路由 ER2260T 通过策略路由分流，目标地址国内 IP 或者源地址旁路网关直接上行宽带提供商，其余绕行旁路网关。再在旁路网关上走代理出去……