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容量限制之间的大小取舍关系）
Table of Contents
Fastcgi的上限：通过tmpfs设置还是通过nginx config设置
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的容量上限：
也就是说缓存容量会先触及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的容量上限：
也就是说缓存容量会先触及nginx config的上限
假设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
以上讨论的都是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的访问可用（使用ramfs时， 缓存容量会先触及nginx config的上限 ，所以不会出现520/521报错）
所以回到这篇笔记的开头部分，我在本站的服务器架构中使用ramfs代替了tmpfs.
