配置推送錯(cuò)誤導(dǎo)致DB被kill
【編者按】這是日常環(huán)境發(fā)生的一起mysql收到kill信號的問題，作者維西（@維西V ）將其整理如下：
【問題表現(xiàn)】
在功能測試時(shí)，mysql經(jīng)常被kill掉，有較統(tǒng)一的時(shí)間間隔：
gbk可以看到是明確的kill 信號
【問題原因】
首先排除了人為后臺(tái)腳本進(jìn)行kill，檢查環(huán)境時(shí)發(fā)現(xiàn)ulimit 有異常參數(shù)：
- $ ulimit -t
- 300
- (-t The maximum amount of cpu time in seconds)
- (實(shí)際上為，進(jìn)程消耗cpu的總量，達(dá)到閾值后會(huì)自己被kill)
【影響范圍】
SQA的DB機(jī)器8臺(tái)，web app機(jī)器5臺(tái)
【問題分析】
標(biāo)準(zhǔn)DB模版clone中，和ulimit相關(guān)的文件如下,(優(yōu)先級低->高)：
- cat /etc/security/limits.d/tops_dba_limits.conf
- * soft nofile 131070
- * hard nofile 131070
- * soft nproc 131070
- * hard nproc 131070
- cat /etc/security/limits.conf
- * soft nproc 131070
- * hard nproc 131070
- * soft nofile 131070
- * hard nofile 131070
所以ulimit -t參數(shù)為默認(rèn)值unlimited，該機(jī)器上的配置文件和clone一致，但運(yùn)行ulimit -t顯示的竟然是300。
經(jīng)排查發(fā)現(xiàn)，OS配置管理時(shí)，一個(gè)任務(wù)為對自己所用資源做限制，
連接進(jìn)來后申明了ulimit -t 300的session參數(shù)
然后該任務(wù)不斷擴(kuò)展，增加了重啟sshd操作，導(dǎo)致后續(xù)ssh進(jìn)來的進(jìn)程繼承了300的配置，導(dǎo)致問題
(新進(jìn)程先繼承session參數(shù)，后讀取OS配置文件，但配置文件未寫出cpu limit，合并后取300)。
【源碼】
- ./kernel/posix-cpu-timers.c:1139
- view sourceprint?
- if (psecs >= sig->rlim[RLIMIT_CPU].rlim_max) {
- /* * At the hard limit, we just die.No need to calculate anything else now.*/
- __group_send_sig_info(SIGKILL, SEND_SIG_PRIV, tsk);
- return;
- }
- if (psecs >= sig->rlim[RLIMIT_CPU].rlim_cur) {
- /* At the soft limit, send a SIGXCPU every second. */
- __group_send_sig_info(SIGXCPU, SEND_SIG_PRIV, tsk);
- if (sig->rlim[RLIMIT_CPU].rlim_cur
- < sig->rlim[RLIMIT_CPU].rlim_max) {
- sig->rlim[RLIMIT_CPU].rlim_cur++;
- }
- }
【改進(jìn)措施】
/etc/security/limits.conf中對all賬號，顯式注明cpu unlimited (soft/hard)
底層配置管理或者批量操作時(shí)，避免使用小眾命令，盡量使用常規(guī)命令和成熟工具。
