放进 tmpfs 的 870 MB 文件，以及随后的重启

8 月 28 日 19:35，我把一天的访问日志解压到 /tmp，好一次读完两天。19:44，机器重启了。

没有被检查的那个属性

在这台机器上，/tmp 是 tmpfs。它是内存。df 显示还有 1.9 GB 可用，却一个字都不说这些空间从哪来，而整台机器一共 3,794 MB。

于是一个 870 MB 的文件进了这台小服务器四分之一的内存里，而它同时还在提供网站服务，并扛着别人的一个测试进程。九分钟后 SSH 不再接受连接，页面要 11 秒才回，而不是 0.1 秒；不久之后它又回来了，运行时间零分钟。

什么能说，什么不能

MariaDB 是带着崩溃恢复起来的，所以关机不干净。除此之外，诚实的回答是：这证明不了。这台机器的 journal 是易失的，撑不过一次重启，也没有任何 kern.log 里写着内存不足。证据就是一个比事件早九分钟的时间戳，和一个放错地方的文件。

这值得就这样写下来，而不是写成结论。「把内存塞满了，内核放弃了」是一个说得通的故事。它不是被测量出来的，而在这里，这个差别比确定性更重。

损失是什么

没有找到任何损失。对五张最重要的表跑 CHECK TABLE 都回 OK，行数没变，当天计数仍在写入，十六个计划任务全都完好。页面又是 0.14 秒回来。

丢了一样东西：同一台机器上属于另一个会话的一个长任务。它和这项工作毫无关系，却和其他一切一起沉了下去 — 而这正是一次故障里没有任何本地检查会报告的那部分。

由此得出的规则

这里的日志文件一天 700 到 900 MB。把一个解压到 /tmp，等于把机器四分之一的内存放进一个看起来像磁盘、表现像内存的地方。

大的中间文件放到 /var/tmp 或者家目录，两者都在磁盘上。更好的是：根本不解压。zcat -f file.gz | awk ... 是流式读取，不需要目的地。后面那些文章里的每一次测量都是这么做的。

这件事的一般化

文件系统会报告它有多少空间。它不报告这些空间是什么做的，而这两个问题的答案，恰恰在最要紧的那些系统上是不一样的。

那个检查只有一行，而它被跳过了，因为那个文件是「临时的」。临时是真的。只是那不是当时该想的那个性质。