使用 tmpfs 提升 Grav 缓存性能
前些日子我对 Grav Admin 的访问速度感到很不满意，经常打开 Dashboard 页面就给我来个 504 Gateway Timeout，不得不再刷新一次才能正常访问；甚至有一次我在编辑页面写了一大段文字之后，保存失败导致内容丢失，后来尝试再写也没法补全丢失的内容。这份不愉快让我萌生了寻找一个更厉害的博客引擎的念头。
但是基本上 Grav 已经是 2016 年最棒的开源 CMS 了，也就是说综合各个方面因素，没有什么比它更好的 CMS 可供选择。失望之余不免产生想要亲自动手造一个轮子，但是考虑到我已经废弃了原本就不怎么突出的前端能力，如今的我已经对实现一个靠谱的博客后台力不从心，这些冲动最终也只是想想而已。
今天不知为何突然天马行空地设想一个牛逼哄哄的博客系统的架构，用 OSGi 实现插件化和插件的热插拔，博客内容和配置都放在 H2 内存库里，然后部署三个实例给 H2 组一个 Raft Group 做容灾，H2 主库上定时打快照做全量备份……
用 H2 给博客做数据库是什么鬼，现在的 CMS 要么就用 MySQL、SQLite 之类的关系数据库，要么就用 MongoDB 之类的 NoSQL，要么直接用 flat file，哪有人用 H2 这种 Java 生态里的内存关系数据库的，性能再好也没人用。
感觉好像发现了什么，数据全放内存里，性能会很好，不管是放在内存数据库，还是直接用哈希表，性能都很好。如果我把 Grav 依赖的文件系统也给放到内存里，Grav 的性能也会很好啊~
如果我把 Grav 操作的目录给替换成内存文件系统了，就会失去持久性，机器重启之后博文就丢失了，回到解放前；为了获取一定程度的持久性，可以定时把文件从内存文件系统用 rsync 增量同步到磁盘文件系统，唯一的风险是重启丢失一个定时周期的数据。
权衡再三，我选择了把 Grav 的 cache 从磁盘文件系统换成内存文件系统，其余目录保持磁盘文件系统不变，这样能获取一部分加速效果，而且是本应该很快但是没快起来的部分变快了，也不需要去做数据定时同步这样的脏活。
sudo mount tmpfs cache -t tmpfs -o size=120m
cache 是 Grav 的缓存目录，设定最大 120 MB，空间用完了在写文件的时候会报 No space left on device 这样的错误信息。
感觉是快了一些，然而并没有实验对比，具体快了多少也不知道，反正感觉是快了一些。
访问 Dashboard 暂时也不会遭遇 504 了，就这么用下去吧~
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
