共 3 篇相关文章
这篇讲的是Linux内核中一个关键性能优化组件——页缓存的工作原理与实现。作者将它比作硬件缓存的软件实现，核心思想是利用快速的主存来缓存慢速的磁盘数据，以此大幅减少I/O等待。 文章首先解释了页缓存的读写机制：读取时先查缓存，若未命中则加载并可能长期驻留；写入时则直接修改缓存中的“脏页”，并不立即写回磁盘，而是采用延迟写回的策略来合并多次修改。 实现上，内核面临两大挑战：如何快速找到特定缓存页，以及如何统一管理来自不同源（如文件、设备）的数据。文章深入剖析了address_space结构如何巧妙地解决这两个问题。它内部维护一棵radix优先搜索树，将所有属于同一所有者的缓存页组织起来，支持高效的查找、插入和删除。同时，通过a_ops钩子函数集，为不同数据源定义了统一的操作接口（如readpage、writepage），让上层逻辑与底层具体设备解耦。 最后，文章列出了内核提供的基本操作函数，如查找、分配、添加和移除缓存页，构成了操作页缓存的程序接口。整体来看，这篇文章从概念到实现，清晰地梳理了Linux内存管理中这一精巧的中间层设计。
这篇讲的是很多人对MySQL的Row Cache存在误解，觉得它能显著提升查询性能。作者从实际测试出发，使用sysbench工具对开启与关闭Row Cache的场景进行了对比压测。 结果发现，在sysbench的典型测试模式下（oltp_read_write等），Row Cache几乎没有带来性能提升，甚至在某些情况下还有轻微下降。文章深入分析了原因：sysbench生成的测试数据通常是随机主键查询，这导致缓存的行数据很快被新数据挤出，命中率极低。 作者通过调整sysbench参数，比如使用顺序扫描或固定查询模式，才观察到了Row Cache的预期效果。这揭示了该缓存机制更适合特定工作负载（如频繁重复读取相同行），而对一般的OLTP场景作用有限。文章最后给出建议：在评估缓存收益时，务必让测试负载贴近真实业务特征。
这篇从Linux内存管理中一个常见却容易混淆的概念切入：Page cache与Buffer cache的关系。作者开篇即点明，许多开发者习惯将两者并列讨论，但实际上它们存在明确的包含与交互层次——Page cache是更上层的抽象，它完全涵盖了Buffer cache；在现代Linux内核的实现中，所有的磁盘I/O操作在内存层面都统一经由Page cache进行管理，内存子系统不再直接与Buffer cache对话。 这种设计巧妙地将文件系统缓存与块设备缓存进行了整合，简化了内存管理的复杂度。文章用清晰的逻辑梳理了这一演变，帮助读者理解为何我们在查看系统内存使用时，Buffer cache的数值会包含在Page cache之内。理解这一点，对于准确分析系统性能、解读`free`命令输出等日常运维场景，能提供一个更坚实的底层认知基础。
