灾难现场
客户需要清理lua内存，于是按照标准动作执行了script flush。发现系统直接hang住了，请求无法执行，超时报错。
开始排查
此时我们开始怀疑是否是清理内存导致了系统hang主，拨测失败，导致HA。然后我们进行了排查验证，果然在管控系统日志中发现了端倪
管控系统HA切换记录然后我们看下当前的lua内存到底是多少？
lua内存果不其然，25G内存清理确实非常耗时，由于腾讯云4.0标准版的redis其实是引入arbiter节点当做集群版来管理，因此我们需要调大节点的timeout值，可以使用config get获取当前值，默认值为
代码语言：txt复制cluster_node_timeout 15000可以看到默认值是15秒，于是我们将该值调整为100秒，重新约定时间，然后客户重新发起。尴尬的情况发生了。
再一次发生了HA切换左右为难
又1次发生了HA切换，命令仍然未执行成功。既然不能云上测试，又不敢随便修改这个值，我们是希望能够通过准确的模拟估计出这个值的大小。于是按照如下方案：
- 先下载备份然后恢复到一个单机版实例
- 执行flush script测试耗时
- 调高cluster node timeout
- 返回线上集群执行
通过导入备份还原一个单机版实例，我们测试的结论如下
单机版执行结论然后再次执行就没问题了
代码语言：txt复制used_memory_lua:41984
used_memory_lua_human:41.00K
used_memory_scripts:624小结
建议如果需要清理，不要堆积到几十个G的时候再进行操作，否则很容易导致HA切换。特别是不要再占用内存很高的情况下使用script flush
Lua占用内存为25.15G，是极不合理的，如果读者遇到这种情况，建议排查内存泄露或者是否使用了动态生成脚本的方式
