ScyllaDB异常重启错误排查

凌晨，钉钉上收到ScyllaDB down的报警，等一下又恢复，如此反复，对数据的读写造成了一定的影响，于是进行对Scylla的错误排查，最终查到异常重启的原因，在这里给大家分享一下如何进行排错的。

从上图中可以看出，这个时间段CPU和内存相对较高，我们再看看Scylla的错误日志，进一步分析异常重启的原因

上图中可以看到是客户端连接异常，没有其他有价值的日志信息，一般来讲，程序日志中看不出来具体错误，有可能是和系统有关。

在系统日志里发现以上红框标记的错误信息，网上查找资料，分析原因

默认情况下， Linux会最多使用40%的可用内存作为文件系统缓存。当超过这个阈值后，文件系统会把将缓存中的内存全部写入磁盘， 导致后续的IO请求都是同步的。

将缓存写入磁盘时，有一个默认120秒的超时时间。 出现上面的问题的原因是IO子系统的处理速度不够快，不能在120秒将缓存中的数据全部写入磁盘。

IO系统响应缓慢，导致越来越多的请求堆积，最终系统内存全部被占用，导致系统失去响应。

1、升级服务器配置，最简单的办法，不过成本比较大

2、针对上面的问题原因分析，缓存写入磁盘时间默认120秒，我们可以调整缓存写入磁盘的频率，避免因为请求堆积而导致系统异常。
vim  /etc/sysctl.conf 
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

vm.dirty_background_ratio: 是内存可以填充脏数据的百分比。这些脏数据稍后会写入磁盘，pdflush/flush/kdmflush这些后台进程会稍后清理脏数据。比如，我有32G内存，那么有3.2G的脏数据可以待着内存里，超过3.2G的话就会有后台进程来清理。
vm.dirty_ratio: 是可以用脏数据填充的绝对最大系统内存量，当系统到达此点时，必须将所有脏数据提交到磁盘，同时所有新的I/O块都会被阻塞，直到脏数据被写入磁盘。这通常是长I/O卡顿的原因，但这也是保证内存中不会存在过量脏数据的保护机制。