一、业务主机以及数据库最近的3次故障现象
4月25号凌晨01:00左右业务主机因为电源问题宕机，当天晚上修复。
4月30号下午15:00左右业务内存数据库宕库。
5月5号下午17:00左右业务内存数据库宕库。
二、内存数据库宕库的原因分析
2次宕库在内存数据库层面都没有任何错误日志抛出，Altibase厂家认为不可能是他们的问题，可能是操作系统问题，有可能是环境变量之类的问题。在对比2次宕库的时间间隔和业务内存数据库主库和备库的环境设置之后，发现有个参数设置不同：
业务host1:/home/altibase> ulimit -a
time(seconds) 2097151
业务host2:/home/altibase> ulimit -a
time(seconds) unlimited
该参数的作用是限制一个进程累计的最大cpu时间片值，当altibase进程消耗的CPU总时间达到这个值的时候，altibase进程就被操作系统给kill掉了。
由此可以估算宕库的间隔时间为：
2097151秒/(24*3600)/(16（我们系统有16颗CPU）*32%（平均的CPU使用率）) = 4.7天
在业务的测试环境上，对这个参数也进行了4次模拟测试，测试结果与上述分析相符，4次都发生了宕库，可以确定宕库的原因就是这个参数的设置问题。
三、解决办法
调整操作系统的参数设置，具体命令如下：
chuser cpu='-1' cpu_hard='-1' altibase
实际上上面两个参数中起作用的是cpu，即soft_cpu
该参数现已调整，安排进行一次内存数据库的重启，就可使新的参数设置生效。
4月25号凌晨01:00左右业务主机因为电源问题宕机，当天晚上修复。
4月30号下午15:00左右业务内存数据库宕库。
5月5号下午17:00左右业务内存数据库宕库。
二、内存数据库宕库的原因分析
2次宕库在内存数据库层面都没有任何错误日志抛出，Altibase厂家认为不可能是他们的问题，可能是操作系统问题，有可能是环境变量之类的问题。在对比2次宕库的时间间隔和业务内存数据库主库和备库的环境设置之后，发现有个参数设置不同：
业务host1:/home/altibase> ulimit -a
time(seconds) 2097151
业务host2:/home/altibase> ulimit -a
time(seconds) unlimited
该参数的作用是限制一个进程累计的最大cpu时间片值，当altibase进程消耗的CPU总时间达到这个值的时候，altibase进程就被操作系统给kill掉了。
由此可以估算宕库的间隔时间为：
2097151秒/(24*3600)/(16（我们系统有16颗CPU）*32%（平均的CPU使用率）) = 4.7天
在业务的测试环境上，对这个参数也进行了4次模拟测试，测试结果与上述分析相符，4次都发生了宕库，可以确定宕库的原因就是这个参数的设置问题。
三、解决办法
调整操作系统的参数设置，具体命令如下：
chuser cpu='-1' cpu_hard='-1' altibase
实际上上面两个参数中起作用的是cpu，即soft_cpu
该参数现已调整，安排进行一次内存数据库的重启，就可使新的参数设置生效。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/10867315/viewspace-694924/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
