hived使用shared_memory.bin来保存一些状态信息(可以粗暴地理解成hive区块链系统的内存），这个文件可以在配置文件中指定其大小。
(图源 ：pixabay)
在HIVE hardfork 25的时候，我记得这个文件实际占用空间约18G左右（STEEM时代我没记错的话，要60个G左右），因为它增长起来不是那么迅猛，所以我在配置文件中将其设置为20G，亦即：
shared-file-size = 20G
其实配置文件中还有两条参数可以设置让这个文件在不够用的时候自己扩容，分别为：
shared-file-full-threshold = 0以及shared-file-scale-rate = 0
设置为0代表的是禁止自动扩容，至于如何设置才能让其自动扩容，大家可以参考这两条参数的注释信息，这里就不再赘述了。
好了，其实我要说的就是：我将shared_memory.bin的大小设置为20G，并且没有设置自动扩容（我习惯自己上手弄）。
如果这个shared memory和以前一样增长缓慢，那么没啥问题。但是一旦shared memory的增长大于shared_memory.bin的大小，并且没有设置自动扩容，可能就会导致hived的崩溃或者其它意想不到的问题。所以我时不时的瞧一眼，看看有没有爆炸的风险。
话说，前两天登录自己见证人节点的VPS，习惯性的进入到对应目录，打下du -sh *，结果如下：
这一看，可把我吓出一身冷汗，shared memory已经用到21G了吗？怎么这么突然？怎么我的节点还没有炸？于是赶紧看了一眼配置文件，发现自己并没有设置自动扩容啊。
这真是让我百思不得其解，向大神请教后，他说他记得这个文件应该只占用18G，我记得也差不多啊。突然想起来，我可以看看我的其它节点啊，于是看了一眼本地电脑上运行的节点：
咦，这里，shared_memory.bin占用空间为18G，看起来就是正常的。按说两个节点，我配置几乎一样，没道理一个shared memory占用多，另外一个占用少啊？
想来想去，我想到以前曾经注意到的一个事实，那就是shared_memory.bin是作为稀疏文件（Sparse File）创建的，也就是说，它创建之初，是20G的稀疏文件，然后数据一点点填充进去的。
现在查看我本地机器上的shared_memory.bin，还能看到一些端倪，du -sh *，显示结果上边已经贴了，再来看看ls -lh：
看出来差异了没有？du显示的空间占用为18G，而ls显示的文件大小为20G，这就是稀疏文件喽，18G以后的空间（未被使用到的）用元数据来表示，不占用实际空间。
其实除了du以外，我们还可以使用ls -lsh来查看实际分配的空间大小：
其中，-s选项的意义是显示文件的已分配空间。对应到shared_memory.bin这个文件，就是文件大小是20G，已经分配18G。
好了，那么问题来了，对应到我的见证人节点，发生了什么事情，让shared_memory.bin变胖了呢？我想来想去，想到一件事情，就是这个文件我不是在那台VPS上创建的，而是用scp从其它VPS上复制过来的。
我查了网上一些资料，也看了scp的手册man scp，貌似它还不支持复制稀疏文件。所谓的不支持不是复制不了，而是将其当作普通文件，空洞（元数据表示空间），自动被填充上0，所以文件就变胖了。
据说，可以使用tar（-S, --sparse）先打包，然后再用scp复制，就可以啦，关于-S, --sparse参数：
Handle sparse files efficiently. Some files in the file system may have segments which were actually never written (quite often these are database files created by such systems as DBM). When given this option, tar attempts to determine if the file is sparse prior to archiving it, and if so, to reduce the resulting archive size by not dumping empty parts of the file.
另外，hive启动时也会检查“内存”（此内存不是系统的内存哦），比如我本地节点看起来“内存”充裕：
check_free_memory ] Free memory is now 3G. Current block number: 57153019
简单来说，就是我使用scp拷贝shared_memory.bin导致稀疏文件（Sparse File）中的空洞被填充，文件变胖了。
(图源 ：pixabay)
搞明白这些个问题后，我总算松了一口气，也就是说，我的见证人节点shared_memory.bin空间还够用，暂时不会炸，虚惊一场。再纠结要不要设置hared-file-full-threshold以及shared-file-scale-rate，哎，先这么着吧，得过且过。