> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20230102-gou-jian-freebsd-web-fu-wu-qi/we-get-letters.md). # 读者来信 * 原文：[We Get Letters](https://freebsdfoundation.org/wp-content/uploads/2023/02/JanFeb_letters.pdf) * 作者：**MICHAEL W LUCAS** 亲爱的 FreeBSD 来信专栏作家： 你好吗？我挺好的。呃，差不多吧。算不错吧。好吧，其实我一点都不好。我是新系统管理员，完全摸不着门道，希望你能给点指点。我正在搭一台新 Web 服务器，跟这期主题一样，但我卡在安装程序里。我听说了好多关于针对不同应用优化文件系统的事，博客上优化的文章多如牛毛，可我不知道该听谁的。我搭好的东西，接下来好些年都得受着！请帮我在选择上少犯点错。 ——新系统管理员 亲爱的 NS： 你的信给我带来了一丝安慰，因为它让我能暂且把那些 2017 年搭的 Web 服务器、1992 年的 Sendmail 配置之类的麻烦事抛到脑后。就像为了忘掉脓肿的牙疼，把肋骨打断几根一样。干得漂亮！ 你可能是新系统管理员，但至少你懂得：在服务器的生命周期里，你都得为你那些糟糕的决定买单。是的，你可以 DevOps 一点，动态用改进的设置重新部署主机，但你做的不过是把忍受一套坏决定的时间缩短，然后换上另一套同样糟糕的。换一组烂选择，不如歇一阵子。 ## 安装时怎么为数据库优化文件系统？ 安装时怎么为数据库优化文件系统？我的答案是：别这么干。过早优化是万恶之源，紧随其后的是糟糕的权限管理和 nano。在真实负载下运行应用之前，你根本不知道数据库会和文件系统如何互动。唯一明智的选择，是把新系统安排成有空盘可挪数据库上去的样子。是的，这基本和 devops 到新主机一样，只不过这不是新主机，也不需要 Ansible。如果你用的是那种提供块存储的虚拟主机服务商，挺好，只不过你得在那些块上格式化文件系统。“云”其实是“别人的计算机”，而“块存储”其实是“别人扔掉的硬盘组成的廉价垃圾冗余阵列”。它的主要优势是，你不是那个需要追着报警声找到硬盘托盘的人。 如果你坚持要优化文件系统，行，听我说。 首先，要明白存储设备是撒谎的骗子，谎话连篇。最新的固态存储与前一个世纪的硬盘保持着一种畸形的兼容，那些硬盘建立在为打孔卡设计的标准之上，而打孔卡源于 17 世纪的织布机和卢德分子，所以你每插上一台存储设备，就有人失业，但资本主义下没有伦理数据存储这回事，所以放手干吧。需要让你警惕的主要谎言是扇区大小。今天的硬盘压倒性地使用 4K 扇区，除了一些支持多种扇区大小的 NVMe 设备，但我没有这种设备，所以假装它们不存在。你要确保你硬盘上的分区——是分区，不是文件系统——和那些 4K 扇区大小对齐。如果你喜欢的那种花哨启动加载器需要一个 98K 的 GPT 分区，它占掉 19.5 个磁盘扇区。硬盘自称会替你兜底，那又是谎话。下一个分区最好从 100K 开始——4 的漂亮倍数——否则你所有的文件系统块都会横跨两个磁盘扇区，每次和硬件打交道都要花两倍时间，硬盘烧得也快一倍。分区分好之后，文件系统块也必须是 4K 的倍数。ZFS 默认 128K 条带。UFS 默认块大小 32K，能用 4K 的碎片，所以原本就该没问题。但别自作聪明觉得块越小性能越好，因为——不管一堆老博客怎么说——并不是。 行了。你可以向管理层报告，文件系统已针对硬件调优完毕。回去玩 nethack 吧。 但我听见你们中有人嘀咕：那只是分区。文件系统呢？文件系统需要调优！胡说八道，我说！你不会去调金枪鱼（tuna fish），为什么要调文件系统？文件系统是给懒人写的。让它去，它给你造成的痛苦，不过是它的程序员坚持要给你的那么些，而且那也是因为市场部坚持“计划性淘汰”以逼着人升级。BSD 操作系统不以盈利为目的，用户痛苦会增加支持工单量，所以文件系统的折磨被有条不紊地削减，所剩无几。如今用文件系统几乎够不上“折磨”二字。任何改动多半会增加你的痛苦。 你还在？还想听建议？ 嗯。你该知道心理治疗师就是靠给像你这样的人咨询谋生的吧？ 行。 你的文件系统应该反映你的数据。如果你知道你的数据是大量 64KB 的文件，可以把块设到那个大小。你了解自己的数据，自己应该能算出来。如果你的数据不那么可预测，就别优化。 数据库能让最疲倦的系统管理员也动了优化文件系统的念头。数据库有可预测的块大小。MySQL 用 16K 块，所以你可以把底下的 ZFS dataset 的 recordsize 配成 16K。MySQL 能压缩数据，ZFS 也能。压缩已经压缩过的数据是浪费系统资源。研究你的应用，挑一个压缩数据的地方。 不要把 UFS 配成 16K 块，即便它跑 MySQL。一个 UFS 块有 8 个碎片，由于底层磁盘，每个碎片最小是 4K。把两个 UFS 碎片塞进一个磁盘扇区会击碎性能。把 MySQL 安装调到使用更大的 UFS 块或许有意义，但再说一遍，文件系统别动。 Postgres 呢？默认到处都是 8K 块。同样，把数据库调到匹配磁盘或许有意义，但 ZFS 或 UFS 上的 8K 块会毁掉系统性能。如果你的数据确实需要 8K 块，最佳选择是用 ZFS 并把 record size 设为 8K。 但总的来说，坏就坏着吧，除非你想搞得更糟——而这在不愿意接受心理治疗的人里很常见。不过放心，挣扎几个月去理解应用和文件系统的交互，你就能成为资深系统管理员。 你这可怜虫。 有问题想问 Michael？请发送至 **MICHAEL W LUCAS** 著有五十多本书，联合国“让 Lucas 闭嘴特使”被一摞书意外地有意压扁了。他写过一本关于 UFS 的书，两本关于 ZFS 的书。由于 ZFS 那两本是和 Allan Jude 合著，所以也许里面真有点有用的东西。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://freebsd-journal-cn.bsdcn.org/20230102-gou-jian-freebsd-web-fu-wu-qi/we-get-letters.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.