This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.所以现在本站的ramfs以及fastctgi size设置如下（2024年5月的数据）：
前提：运行preload.py完毕后，fastcgi的文件夹体积大约28M.
nginx配置文件：key_zone/max_size：50MB.
使用ramfs而不是tmpfs，ramfs挂载时不需要声明容量（声明了也没用），见：🔗 [有关ramfs的一些测试 - Truxton's blog] https://truxton2blog.com/some-ramfs-experiments/
下面是原文：（主要讨论tmpfs容量限制和nginx conf max_size容量限制之间的大小取舍关系）
tmpfs的性能很高，为了尽可能提高网站响应速度，我们可以把nginx fastcgi的缓存文件夹设置为tmpfs .
但要注意一个问题：空间大小的设定。由于tmpfs的大小是固定的，而且不容易“智能”扩容，所以要注意空间不够的问题。
下面会讨论到两种相关的设置参数：
- keys_zone/max_size：写在nginx配置文件里，由nginx控制fastcgi缓存文件夹的空间大小
- tmpfs size：挂载tmpfs磁盘的时候设定的大小，由operating system控制tmpfs的空间大小
下面有2种设置：
1，在nginx里面设置keys_zone/max_size的数值大于tmpfs的容量上限：
假设key_zone设置为WORDPRESS:500m，max_size设置为500M，但tmpfs只有50M，而你的wordpress因为种种原因需要产生60M的缓存文件。
结果就是：nginx会任由tmpfs里面的fastcgi缓存文件夹不断变大（因为还没有到达500M，所以nginx不会有任何动作），一旦fastcgi文件夹的体积到达50M，任何新的url请求都会直接返回520/521错误。除非你手动删除缓存文件，否则这已经产生的50M缓存文件应该是不会被替换掉了，直到它们过期。
总之就是：超出规格的新url一律报错，老url一直保存。
2，在nginx里面设置keys_zone/max_size的数值小于tmpfs的容量上限：
假设key_zone设置为WORDPRESS:40m，max_size设置为40M，tmpfs有50M，而你的wordpress因为种种原因需要产生60M的缓存文件。
一旦产生了40M的缓存文件，nginx会自动把最老的那个缓存文件删掉，使用新的缓存文件代替（* “最老的缓存文件”规则存疑，我没仔细核对过，但肯定会替换掉一个早先的缓存文件）。这个时候访问新的url，你会发现新的url仍然能访问；访问一个比较早的缓存链接，你会发现它也能访问，只是第一次访问的速度变慢了（因为缓存被删掉了，要重新生成一个缓存）。
总之就是：你可以一直不断的访问新的url，不会出现报错。新url的缓存会替换老url的缓存。
同时还要注意：nginx删除老url的缓存的速度有的时候并不是那么快，你会发现缓存文件夹的大小有时会超出key_zone/max_size一点点。所以不建议你设置keys_zone/max_size正好等于tmpfs的体积，还是给tmpfs多预留一点空间比较好。
总结起来就是：为了防止出现报错，还是推荐策略2：nginx里面设置keys_zone/max_size的数值小于tmpfs的体积，并给tmpfs预留一定的空间容错。
Example：keys_zone=WORDPRESS:40m, max_size=40M，tmpfs设置为50M，你的Wordpress网站在所有页面都缓存完毕后会产生大约32M的fastcgi缓存文件。
同时，预留的空间还是要大一些（比如上面的例子里：预留50M - 40M = 10M），因为Google现在会额外访问每篇文章的/feed/页面：🔗 [How to stop Googlebot from crawling /feed pages on my WordPress website? - Google Search Central Community] https://support.google.com/webmasters/thread/89420842/how-to-stop-googlebot-from-crawling-feed-pages-on-my-wordpress-website?hl=en. 一个wordpress网站使用preload生成全部缓存页面后（假设不preload /feed/页面），如果观察fastcgi文件夹，会发现在接下来的几天，这个文件夹会越来越大，里面多了很多新的缓存文件，因为Google Bot开始逐步访问/feed/页面。但这些/feed/页面大概率具有更高的缓存优先级，一旦nginx认为空间不足，那些老的、真正有用的html缓存就会被删除，这显然不是我们想要的。
以上讨论的都是tmpfs.
本文的内容可以拓展到ramfs，但要注意ramfs的一个重要特点（控制不好的话就成了缺点）：
One downside of ramfs is you can keep writing data into it until you fill up all memory, and the VM can't free it because the VM thinks that files +should get written to backing store (rather than swap space), but ramfs hasn't got any backing store. Because of this, only root (or a trusted user) should be allowed write access to a ramfs mount.
https://wiki.debian.org/ramfs
根据本篇笔记对tmpfs/nginx conf max size的讨论结果，在nginx配置文件里限制fastcgi的缓存大小更为科学：
- ramfs占用体积不会无限增长，服务器不会因为RAM被ramfs吃完而崩溃
- ramfs无需声明预留空间，随取随用（也随时回收），fastcgi要用空间多少它就占用多少RAM，对RAM的使用更加高效合理
- 始终都能保持网站所有url的访问可用（不会出现520/521报错）
所以回到这篇笔记的开头部分，我在本站的服务器架构中使用ramfs代替了tmpfs.
