性能优化
每个人都应该知道的操作时间
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-05-24
Huge Page：TLB 压力和页表开销
上一篇讲了 NUMA 如何让内存访问不再均匀。但即使在单 node 系统上，当工作集足够大时，另一类开销浮现：TLB miss 和页表自身的内存消耗。Huge page 通过增大映射粒度来同时缓解这两个问题。 核心问题可以压成一句话： huge page 用更大的映射粒度减少 TLB 和页表开销，但引入碎片、分配时机和回收复杂度作为代价。 问题从哪里来 标准页大小 4KB。一个 64GB 内存的机器有 1600 万个物理页。如果一个进程映射了 8GB 工作集，对应 200 万个 PTE。 TLB（Translation Lookaside Buffer）是 MMU 的地址翻译缓存。现代 CPU 的 L1 dTLB 通常只有 64-128 个条目，L2 sTLB 有 1024-2048 个条目。200 万个活跃页面对 2048 个 TLB 条目意味着 TLB 覆盖率不足 0.1%——绝大多数访问要走 page table walk。 page table walk 不是免费的。它需要 4-5 次内存访问（每级页表一次），即使有 page walk cache 辅助，在 TLB...
2026-08-06
深入 Logstash 06 - dissect 与结构化 filter：放弃回溯换吞吐
官方基准里，同条件单 filter 的 dissect 比 Grok 快一成到两成。这个数字小到不值得为它改配置。dissect 真正值钱的地方在另一头：它不用正则引擎，回溯那条会让单条 event 从微秒跳到秒级的路径在它这里根本不存在。 顺着这个判断往下，本篇落到三件具体的事：线性扫描的每一步怎么走、dissect 的语法能覆盖到哪、以及同一个管道里 dissect 和 Grok 怎么分工。 123456789101112131415同一行日志，两条处理路径：message: "2026-08-06T13:40:00 INFO pay-svc user=42 amount=99.50" │ ├── dissect ──── 找分隔符 ──── O(n) 线性扫描 ──── 字段 │ 无正则引擎 │ 无回溯 │ └── grok ─────── ...
2026-05-23
页回收：kswapd 和 direct reclaim
上一篇讲了内核如何用 LRU 近似和 workingset 检测来判断"谁冷谁热"。判断完之后，实际把页面释放出来的工作由回收子系统完成。回收不是一个单点事件，而是围绕水位线、后台线程和分配路径形成的一套压力响应机制。 核心问题可以压成一句话： 回收是围绕水位线的分级压力响应，不是耗尽后的单点动作。 问题从哪里来 内存分配在 Linux 里几乎无处不在：用户态 malloc 背后的匿名页、page cache 的文件页、内核自己的 slab 对象。每次分配都从 buddy allocator 拿物理页。物理页是有限的。 如果等到完全分配不出页面再回收，分配方会被阻塞很长时间——回收可能涉及写脏页、等待 I/O、遍历反向映射。这种"等到没有了才动"的策略延迟不可控。 Linux 的做法是提前开始。内核设定一组水位线（watermark），在不同压力级别触发不同强度的回收。大部分情况下由后台线程 kswapd 在压力升起时提前回收；只有来不及时才在分配路径上直接回收（direct reclaim）。 水位线模型 每个 zone 有三条基本...
2026-08-06
深入 Kibana 15 - 性能模型：bundle、bootstrap 与异步搜索会话
插件数量增长会直接推高前端包体和启动成本，长查询又要求结果能够在页面离开后继续保存。Kibana 的性能治理因此同时覆盖 bundle 拆分、bootstrap 顺序和后台搜索。这里的“搜索会话”在 8.15 起已经进入弃用路径，9.0 默认关闭，9.2 之后由 background search 接棒。本篇把首屏加载与后台查询放在一张性能模型里讨论。 前端 bundle 体系 Kibana 的前端代码量巨大。Discover、Lens、Dashboard、Maps、Security、Observability 加在一起，编译后的 JavaScript 体积以百 MB 计。如果把所有代码打成一个 bundle 让用户一次性下载，首屏时间会无法接受。 Kibana 的解法是三层 bundle 结构。 12345678910111213浏览器请求 Kibana 页面│├── bootstrap.js 核心 shell，极小，总是先加载│ └── 初始化运行时，注册模块加载器，决定加载哪些插件│├── core bundle 平台公共服务│ ...
2026-05-24
回到工程：Linux VM 如何改变性能诊断
前面 16 篇从地址空间到 OOM，逐层拆解了 Linux 虚拟内存子系统的结构和机制。这些知识的价值不只在于读源码——更在于它提供了一种分层诊断习惯：遇到内存相关的性能问题时，先定位层次，再找对象，再看状态转移，最后用指标验证。 核心问题可以压成一句话： Linux VM 的价值不只在源码知识，而在一种分层诊断习惯：先定位层次，再找对象，再看状态转移，最后用指标验证。 系列概念地图 整个系列覆盖的层次和对象： 1234567891011121314151617181920212223用户空间视角 内核视角───────────── ──────────malloc / mmap VMA (vm_area_struct) ↓ 虚拟地址 ↓page fault 页表 (PGD→P4D→PUD→PMD→PTE) ↓ 物理页分配 ↓RSS 增长 ...
2026-06-26
深入 Elasticsearch（14）：搜索延迟、写入吞吐与调优思路
上一篇解决了 segment 和索引的生命周期管理——merge 控制 segment 数量，ILM 管理索引的存储分层。这一篇进入 ES 的性能瓶颈在哪里、调优的思维框架是什么。 性能调优不是背参数表。参数是工具，瓶颈定位才是方法。ES 的性能受搜索延迟和写入吞吐两个维度的独立因素影响，先确定瓶颈在哪个维度的哪个因素上，再针对性调整。 本文只抓一个问题：ES 的性能模型——搜索延迟和写入吞吐分别受什么因素影响，用什么工具定位瓶颈。 搜索延迟的关键因素 1搜索延迟 = f(segment数, query复杂度, shard数, cache命中率, 数据结构选择) 因素 影响机制 观察方式 Segment 数量 每个 segment 独立搜索，结果合并 _segments API Query 复杂度 深层嵌套 bool、wildcard、regexp 代价高 _search?profile=true Shard 数量 scatter-gather 开销随 shard 数线性增长 _cat/shards Filesystem cache Lucene 文件...