給大家分享一個案例分析-比較偏僻

一、業務主機以及資料庫最近的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
    該引數現已調整，安排進行一次記憶體資料庫的重啟，就可使新的引數設定生效。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10867315/viewspace-694924/，如需轉載，請註明出處，否則將追究法律責任。