性能优化
每个人都应该知道的操作时间
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
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-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 文件...
2026-10-05
区块链（37）：比较吞吐之前先定义哪一种完成
把本机 SQLite 事务每秒完成数与公链每秒提交数写在一张柱状图，不是同条件对比：前者可能只是单机持久化确认，后者可能只是在远端 RPC 接受待处理交易。区块链（36）：节点备份、RPC 与终局停滞不能混成“服务异常”的链头延迟和终局停滞，也不能压成一个平均请求耗时。 flowchart LR S[客户端发送] --> R[RPC 接收] R --> I[区块纳入] I --> E[执行成功] E --> F[按网络定义终局] F --> B[业务条件与资产对账完成] 固定硬件、节点数、软件 SHA、网络拓扑、负载分布、批次大小、资产类型和成功定义，分别报提交延迟、纳入延迟、执行失败比例、终局/业务延迟及尾部值。成本同时包含用户交易费、节点 CPU/内存/磁盘/带宽、证明生成与验证、运维备份和争议期资金占用；不能只用低平均 gas 宣称总体最便宜。安全模型也不同：许可网络牺牲开放性，rollup 可能依赖 L1 数据和有权退出的桥，传统数据库则依赖运营者。 先定义可复算的测量记录 对于订单 o，保留五个不同的 UTC 时间戳：t...
2026-06-20
性能模型：吞吐、延迟与调优思路
前面的文章覆盖了 Kafka 的核心机制和生态组件。这一篇回到工程视角：Kafka 的性能模型到底长什么样。 性能调优容易变成一张参数清单。更有效的方式是先建立一个吞吐-延迟的基本模型，再用这个模型解释每个参数的作用方向和代价。 本文只抓一个问题：Kafka 的吞吐和延迟分别由哪些因素决定，调节一个参数时另一端会发生什么变化。 性能基础：四个底层机制 Kafka 的高吞吐不是来自某个单一优化，而是四个机制叠加的结果。 1234567891011Producer Broker Consumer | | | |-- batch N records ---->| | | (linger.ms window) |-- sequential append --> | | | (page cach...
2026-10-01
容器 34：冷启动时间花在哪一段
拿一条从 docker run 到终端提示的总耗时，无法推断是拉取慢、快照准备慢、进程启动慢还是应用就绪慢。先定义测量的边界与可关联的对象，然后谈数值。 同一只 Pod 在两台节点的“启动耗时”可能相差很大：一台已有内容存储和快照，另一台要从 registry 取层；应用的探针又可能固定等待十秒。只看 kubectl wait 结束时刻，连缓存条件都无法还原，更谈不上给 OCI create 分配多少毫秒。本篇把一次启动拆成控制面可见事件、节点运行时原始事件、应用首次就绪三条时间轴；先标记哪些区间目前还不可观测，再决定能不能比较冷、热启动。 先写实验设计，后写结论 同一 probe-app 固定 image digest、节点 CPU 架构、内核与运行时版本，在专用 VM 上分冷缓存与热缓存两组。时间戳分别落在开始拉取、manifest/layer 验证结束、本机解包与 snapshot 准备结束、OCI create/start、进程首条日志、/ready=200。对同一 ID 记录事件时钟来源，跨组件不能把不同机器的墙钟未经校准就做相减。预先确定预热次数、重复次数、并发、输入...
2026-05-23
页回收：kswapd 和 direct reclaim
上一篇讲了内核如何用 LRU 近似和 workingset 检测来判断"谁冷谁热"。判断完之后，实际把页面释放出来的工作由回收子系统完成。回收不是一个单点事件，而是围绕水位线、后台线程和分配路径形成的一套压力响应机制。 核心问题可以压成一句话： 回收是围绕水位线的分级压力响应，不是耗尽后的单点动作。 问题从哪里来 内存分配在 Linux 里几乎无处不在：用户态 malloc 背后的匿名页、page cache 的文件页、内核自己的 slab 对象。每次分配都从 buddy allocator 拿物理页。物理页是有限的。 如果等到完全分配不出页面再回收，分配方会被阻塞很长时间——回收可能涉及写脏页、等待 I/O、遍历反向映射。这种"等到没有了才动"的策略延迟不可控。 Linux 的做法是提前开始。内核设定一组水位线（watermark），在不同压力级别触发不同强度的回收。大部分情况下由后台线程 kswapd 在压力升起时提前回收；只有来不及时才在分配路径上直接回收（direct reclaim）。 水位线模型 每个 zone 有三条基本...