配置推送錯(cuò)誤導(dǎo)致DB被kill
【編者按】這是日常環(huán)境發(fā)生的一起mysql收到kill信號(hào)的問(wèn)題,作者維西(@維西V )將其整理如下:
【問(wèn)題表現(xiàn)】
在功能測(cè)試時(shí),mysql經(jīng)常被kill掉,有較統(tǒng)一的時(shí)間間隔:
gbk可以看到是明確的kill 信號(hào)
【問(wèn)題原因】
首先排除了人為后臺(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)
【問(wèn)題分析】
標(biāo)準(zhǔn)DB模版clone中,和ulimit相關(guān)的文件如下,(優(yōu)先級(jí)低->高):
- 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
所以u(píng)limit -t參數(shù)為默認(rèn)值unlimited,該機(jī)器上的配置文件和clone一致,但運(yùn)行ulimit -t顯示的竟然是300。
經(jīng)排查發(fā)現(xiàn),OS配置管理時(shí),一個(gè)任務(wù)為對(duì)自己所用資源做限制,
連接進(jìn)來(lái)后申明了ulimit -t 300的session參數(shù)
然后該任務(wù)不斷擴(kuò)展,增加了重啟sshd操作,導(dǎo)致后續(xù)ssh進(jìn)來(lái)的進(jìn)程繼承了300的配置,導(dǎo)致問(wèn)題
(新進(jìn)程先繼承session參數(shù),后讀取OS配置文件,但配置文件未寫(xiě)出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中對(duì)all賬號(hào),顯式注明cpu unlimited (soft/hard)
底層配置管理或者批量操作時(shí),避免使用小眾命令,盡量使用常規(guī)命令和成熟工具。