今天去Mattermost上的HIVE见证人聊天频道去看看，这个频道是我关注的HIVE频道之一，大家在里边聊和见证人有关的消息，我时不时地去关注一下，以免错过最新消息。
(图源 ：pixabay)
然后今天看到一位见证人在聊天频道里说，他的两个见证人节点近期都崩溃掉，问大家有没有遇到同样的问题。结果是，大家都没遇到，节点都跑得好好的。
因为我的主备两个节点也一切正常，所以我很赞同群里其它小伙伴给他的回复，既然他的两台节点都同时出问题，那么大概率是他节点配置的问题，或者机房硬件的问题。
对此，我还沾沾自喜，看看，咱这配置久经考验了，再说咱这机房——哎，机房还是不夸了，出过好几次物理机故障了。不过好在我主备节点没有放在一个区域，更不可能放在一个物理机上，所以尽管有时一台出故障，但是只要切换及时，问题并不大。
不过我还是很好奇，这个朋友的见证人节点到底是因为啥而崩溃的呢？过了不久他上传几张截图，里边有节点崩溃前的显示的消息，其中几条消息很有参考信息。
那就是两个崩溃的节点都有有个“check free memory”操作，提示：
Memory is almost full, increasing to 22528M.
然后应该是执行了分配内存的操作，之后“check free memory”操作又提示：
Free memory is now 3071
在这之后，他的两个节点就崩溃掉了。我当时还在考虑时不时和节点的内存有关呢，这时
There could be a bug around increasing memory ( autoscale the shared memory file). To avoid it, set shared-file-size to a larger value
看来还是大神厉害，一眼就看穿问题所在并且给了如何解决问题的回复。
我正在那羡慕大神呢，突然觉得哪里不对劲呢？啊，我想起来了，我的见证人节点shared_memory.bin的大小直接设置为20G，虽然没有设置shared-file-full-threshold(自动扩容)，但是按着这个朋友遇到的问题，我节点的shared_memory.bin岂不是也很快就要满了？
shared_memory.bin来保存一些状态信息(可以粗暴地理解成hive区块链系统的内存），如果它满了，那些hived必然要崩溃的，我惊出一身冷汗！
于是赶紧登录我的节点，看了一下shared_memory.bin的占用，还好，还剩几百M，短时间内不会因为内存满了而崩溃。
不过看了一眼5个月以前操作时记录的内容，那时候内存占用还是17G多一点呢：
[check_free_memory ] Free memory is now 3G. Current block number: 57153019
而现在占用竟然19G多，也就是说5个月的时间，增长了2G多的内存。那么我还剩的几百M可能一个月就会被耗光。就是我放任不管的话，一两个月以后节点崩溃是必然的。
于是，赶紧登录的主备节点，将shared_memory.bin的大小调整成25G，这样应该至少大半年内我不必操心啦（至于自动扩容我是不会去使用的啦，万一有BUG就悲催啦）：
shared-file-size = 25G
还好虚惊一场，白白惊出一身冷汗。不过如果不是有其它见证人朋友节点崩溃，如果不是
(图源 ：pixabay)
看来以后要多关注见证人频道，还有要及时检查节点的运行状态，咦要不要写个机器人监控一下shared_memory.bin占用之类的信息呢？有问题及时蜂鸣器报警提醒我，貌似这是个不错的想法，改天弄起来！
还有就是，如果你在跑见证人节点，记得及时把shared-file-size这个值调大一些哦，否则节点有爆炸的风险呢！