启动器的资源账:内存、CPU 与 IO 到底花在哪
文件索引首次建立要 1-3 分钟,索引没建完搜索会漏结果
做容量规划时,看三个数就够了:常驻内存、峰值内存、峰值持续时间。
先说结论
按「峰值 × 1.3」配内存,按「平均 × 2」配 CPU,按「峰值 × 3」留磁盘余量。
- 先量:常驻、峰值、峰值时长
- 内存:注意缓存与 RSS 的区别
- CPU:看是单核瓶颈还是多核瓶颈
- IO:随机读写最伤机械盘
- 扩容前先看是不是配置问题
三个必测的数
不测就调参,等于闭眼改代码:
- 常驻内存(RSS):决定最低配置
- 峰值内存:决定会不会 OOM
- 峰值持续时间:决定要不要限流
- 磁盘日增量:决定备份与轮转策略
内存都去哪了
Raycast 的扩展用 JS 写,一个简单的脚本命令二十行以内。
| 部分 | 典型占比 | 能不能省 |
|---|---|---|
| 运行时/解释器 | 15-25% | 换实现,成本高 |
| 缓存 | 20-40% | 可以限制上限 |
| 连接/会话 | 10-30% | 设上限,及时回收 |
| 日志与缓冲 | 5-15% | 轮转 + 异步写 |
Linux 的 buff/cache 会让人误判内存不足,先看 available 而不是 free。
这个服务的几个资源事实
实测下来,它吃资源的方式比较固定:
- 剪贴板历史是启动器里使用频率最高的功能,超过文件搜索
- Raycast 的扩展用 JS 写,一个简单的脚本命令二十行以内
- 文件索引首次建立要 1-3 分钟,索引没建完搜索会漏结果
- 启动器常驻内存 100-300MB,老机器上能感觉到

CPU 峰值怎么处理
文件索引首次建立要 1-3 分钟,索引没建完搜索会漏结果。
峰值不可怕,可怕的是峰值期间没有排队机制,所有请求一起超时。
扩容还是优化
先做这三件事再谈扩容:限制并发、加缓存、异步化。多数「性能问题」在这三步之后就消失了。
还有几处容易忽略的
都是小地方,但出问题时往往就卡在这里。
- Spotlight 的 ⌘+Space 与第三方启动器冲突,装完第一件事是改键
- 把常用脚本挂进启动器,比记住脚本所在路径实际得多
- 装完不改快捷键,两个启动器一起弹出来
- 把启动器当文件管理器,深层目录还是得开访达
- 剪贴板历史里存了密码,还开了云端同步
性能优化的第一步,是知道自己现在有多慢。
评论 (3)
排查顺序那段直接抄进值班手册了。
版本差异要强调,我照着做结果参数名全变了。
备份没验证过等于没有,这条我认。
发表评论