建站
咨詢
售后
建站咨詢
新聞中心
近年來(lái)，由于全球協(xié)調(diào)時(shí)間（UTC）需要不定期地增加一秒的閏秒，導(dǎo)致許多操作系統(tǒng)都出現(xiàn)了類似于死鎖的問(wèn)題，其中Linux操作系統(tǒng)也不例外。那么，Linux如何應(yīng)對(duì)閏秒導(dǎo)致的死鎖問(wèn)題呢？
10年積累的網(wǎng)站建設(shè)、做網(wǎng)站經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有隆昌免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
閏秒會(huì)導(dǎo)致系統(tǒng)時(shí)鐘的不連續(xù)性，從而引發(fā)一系列的問(wèn)題。在Linux中，閏秒問(wèn)題通常表現(xiàn)為系統(tǒng)進(jìn)程或線程卡死（Deadlock）、網(wǎng)絡(luò)服務(wù)不可用或運(yùn)行異常等現(xiàn)象，從而導(dǎo)致系統(tǒng)失去響應(yīng)。
針對(duì)這一問(wèn)題，Linux系統(tǒng)進(jìn)行了多方面的優(yōu)化和升級(jí)，以更大程度地避免閏秒問(wèn)題的出現(xiàn)。
防止時(shí)間錯(cuò)誤的累積
為了避免時(shí)間錯(cuò)誤的累積，Linux內(nèi)核會(huì)監(jiān)控系統(tǒng)時(shí)間，并在發(fā)現(xiàn)時(shí)間累積一秒時(shí)，立即進(jìn)行調(diào)整，保證系統(tǒng)時(shí)間的正確性。
但是，如果閏秒的處理不當(dāng)，可能會(huì)導(dǎo)致時(shí)間錯(cuò)誤的累積。例如，當(dāng)系統(tǒng)時(shí)鐘出現(xiàn)倒退時(shí)，可能會(huì)觸發(fā)操作系統(tǒng)的時(shí)間戳倒退檢查（Time stamp counter retracing check），從而引發(fā)死鎖問(wèn)題。
因此，Linux內(nèi)核會(huì)對(duì)時(shí)鐘進(jìn)行多輪的同步，確保系統(tǒng)時(shí)間的準(zhǔn)確性。同時(shí)，還會(huì)對(duì)系統(tǒng)時(shí)鐘的調(diào)整進(jìn)行限制，避免頻繁進(jìn)行調(diào)整，從而導(dǎo)致時(shí)間錯(cuò)誤的累積。
優(yōu)化升級(jí)版本
Linux的各個(gè)版本也在不斷地進(jìn)行優(yōu)化和升級(jí)，以更大程度地避免閏秒問(wèn)題的出現(xiàn)。
例如，早期的Linux內(nèi)核版本中，存在時(shí)間累積的問(wèn)題，會(huì)導(dǎo)致系統(tǒng)時(shí)間出現(xiàn)明顯的偏差。而在Linux 4.1版本中，內(nèi)核對(duì)時(shí)鐘進(jìn)行了優(yōu)化，避免了時(shí)間錯(cuò)誤的累積問(wèn)題。同時(shí)，內(nèi)核還添加了timerslack參數(shù)，可以調(diào)整系統(tǒng)時(shí)鐘的頻率，防止時(shí)間錯(cuò)誤的累積。
此外，Linux還對(duì)操作系統(tǒng)的各項(xiàng)服務(wù)進(jìn)行了優(yōu)化和改進(jìn)。例如，對(duì)于NTP（網(wǎng)絡(luò)時(shí)間協(xié)議）服務(wù)，Linux會(huì)自動(dòng)進(jìn)行時(shí)鐘同步，并將時(shí)鐘誤差定為“時(shí)鐘漂移”。當(dāng)閏秒出現(xiàn)時(shí)，系統(tǒng)會(huì)自適應(yīng)地將時(shí)鐘漂移進(jìn)行調(diào)整，避免時(shí)間錯(cuò)誤的累積。
總而言之，Linux系統(tǒng)采取了多種措施來(lái)應(yīng)對(duì)閏秒導(dǎo)致的死鎖問(wèn)題。內(nèi)核會(huì)監(jiān)控系統(tǒng)時(shí)間，并在發(fā)現(xiàn)時(shí)間累積一秒時(shí)，立即進(jìn)行調(diào)整，以保證系統(tǒng)時(shí)間的正確性。通過(guò)優(yōu)化和升級(jí)版本，避免了時(shí)間錯(cuò)誤的累積問(wèn)題。對(duì)于各項(xiàng)服務(wù)進(jìn)行了優(yōu)化和改進(jìn)，自動(dòng)進(jìn)行時(shí)鐘同步，并自適應(yīng)地調(diào)整時(shí)鐘漂移，避免時(shí)間錯(cuò)誤的累積。
雖然閏秒問(wèn)題可能導(dǎo)致一些操作系統(tǒng)的死鎖等問(wèn)題，但通過(guò)Linux系統(tǒng)的多方面優(yōu)化和升級(jí)，已經(jīng)在很大程度上解決了這一問(wèn)題，為系統(tǒng)的高可用性和可靠性提供了保障。
相關(guān)問(wèn)題拓展閱讀：
- 請(qǐng)教linux下用戶態(tài)進(jìn)程調(diào)度問(wèn)題
請(qǐng)教linux下用戶態(tài)進(jìn)程調(diào)度問(wèn)題
在進(jìn)行Linux系統(tǒng)操作的時(shí)候，有時(shí)候會(huì)遇到一次用戶態(tài)進(jìn)程死循環(huán)，即系統(tǒng)反應(yīng)遲鈍、進(jìn)程掛死等問(wèn)題，那么遇到這些問(wèn)題又該如何解決呢？下面小編就給大家介紹下一次用戶態(tài)進(jìn)程死循環(huán)的問(wèn)題該如何處瞎顫理。
Linux下如何處理一次用戶態(tài)進(jìn)程死循環(huán)問(wèn)題
1、問(wèn)題現(xiàn)象
業(yè)務(wù)進(jìn)程（用戶態(tài)多線程程序）掛死，操作系統(tǒng)反應(yīng)遲鈍，系統(tǒng)日志沒(méi)有任何異常。從進(jìn)程的內(nèi)核態(tài)堆?？?，看似所有線程都卡在了內(nèi)核態(tài)的如下堆棧流程中：
?。踨oot@vmc116 ~］# cat /proc/27007/task/11825/stack
?。邸秄fffffff8100baf6》］ retint_careful+0x14/0x32
?。邸秄fffffffffffffff》］ 0xffffffffffffffff
2、喊兄問(wèn)題分析
1）內(nèi)核堆棧分析
從內(nèi)核堆?？?，所有進(jìn)程都阻塞在 retint_careful上，這個(gè)是中斷返回過(guò)程中的流程，代碼（匯編）如下：
entry_64.S
代碼如下：
ret_from_intr：
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
decl PER_CPU_VAR（irq_count）
/* Restore saved previous stack */
popq %rsi
CFI_DEF_CFA rsi，SS+8-RBP /* reg/off reset after def_cfa_expr */
leaq ARGOFFSET-RBP（%rsi）， %rsp
CFI_DEF_CFA_REGISTER rsp
CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET
。。。
retint_careful：
CFI_RESTORE_STATE
bt $TIF_NEED_RESCHED，%edx
jnc retint_signal
TRACE_IRQS_ON
ENABLE_INTERRUPTS（CLBR_NONE）
pushq_cfi %rdi
磨滲敗 SCHEDULE_USER
popq_cfi %rdi
GET_THREAD_INFO（%rcx）
DISABLE_INTERRUPTS（CLBR_NONE）
TRACE_IRQS_OFF
jmp retint_check
這其實(shí)是用戶態(tài)進(jìn)程在用戶態(tài)被中斷打斷后，從中斷返回的流程，結(jié)合retint_careful+0x14/0x32，進(jìn)行反匯編，可以確認(rèn)阻塞的點(diǎn)其實(shí)就在
SCHEDULE_USER
這其實(shí)就是調(diào)用schedule（）進(jìn)行調(diào)度，也就是說(shuō)當(dāng)進(jìn)程走到中斷返回的流程中時(shí)，發(fā)現(xiàn)需要調(diào)度（設(shè)置了TIF_NEED_RESCHED），于是在這里發(fā)生了調(diào)度。
有一個(gè)疑問(wèn)：為什么在堆棧中看不到schedule（）這一級(jí)的棧幀呢？
因?yàn)檫@里是匯編直接調(diào)用的，沒(méi)有進(jìn)行相關(guān)棧幀壓棧和上下文保存操作。
2）進(jìn)行狀態(tài)信息分析
從top命令結(jié)果看，相關(guān)線程實(shí)際一直處于R狀態(tài)，CPU幾乎完全耗盡，而且絕大部分都消耗在用戶態(tài)：
?。踨oot@vmc116 ~］# top
top – 09:42:23 up 16 days， 2:21， 23 users， load average： 84.08， 84.30， 83.62
Tasks： 1037 total， 85 running， 952 sleeping， 0 stopped， 0 zombie
Cpu（s）： 97.6%us， 2.2%sy， 0.2%ni， 0.0%id， 0.0%wa， 0.0%hi， 0.0%si， 0.0%st
Mem：k total，k used，k free，k buffers
Swap：k total， 38644k used，k free，k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
rootm 163m 14m R 10.2 0.5 321:06.17 z_itask_templat
rootm 163m 14m R 10.2 0.5 296:23.37 z_itask_templat
rootm 163m 14m R 10.2 0.5 337:57.26 z_itask_templat
rootm 163m 14m R 10.2 0.5 327:31.93 z_itask_templat
rootm 163m 14m R 10.2 0.5 306:49.44 z_itask_templat
rootm 163m 14m R 10.2 0.5 310:47.41 z_itask_templat
rootm 163m 14m R 10.2 0.5 283:03.37 z_itask_templat
rootm 163m 14m R 10.2 0.5 283:49.67 z_itask_templat
rootm 163m 14m R 10.2 0.5 261:24.46 z_itask_templat
rootm 163m 14m R 10.2 0.5 150:24.53 z_itask_templat
rootm 163m 14m R 10.2 0.5 100:26.77 z_itask_templat
rootm 163m 14m R 9.9 0.5 337:18.77 z_itask_templat
rootm 163m 14m R 9.9 0.5 314:24.17 z_itask_templat
rootm 163m 14m R 9.9 0.5 336:32.78 z_itask_templat
rootm 163m 14m R 9.9 0.5 338:55.08 z_itask_templat
rootm 163m 14m R 9.9 0.5 306:46.08 z_itask_templat
rootm 163m 14m R 9.9 0.5 316:49.51 z_itask_templat
。。。
3）進(jìn)程調(diào)度信息
從相關(guān)線程的調(diào)度信息看：
?。踨oot@vmc116 ~］# cat /proc/27007/task/11825/schedstat
?。踨oot@vmc116 ~］# cat /proc/27007/task/11825/schedstat
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
?。踨oot@vmc116 ~］# cat /proc/27007/task/11825/schedstat
［root@vmc116 ~］# cat /proc/27007/task/11825/schedstat
發(fā)現(xiàn)相關(guān)線程的調(diào)度統(tǒng)計(jì)一直在增加，說(shuō)明相關(guān)線程一直是在被調(diào)度運(yùn)行的，結(jié)合其狀態(tài)也一直是R，推測(cè)很可能在用戶態(tài)發(fā)生了死循環(huán)（或者非睡眠死鎖）。
這里又有問(wèn)題：為什么從top看每個(gè)線程的CPU占用率只有10%左右，而不是通常看到的死循環(huán)進(jìn)程導(dǎo)致的100%的占用率？
因?yàn)榫€程數(shù)很多，而且優(yōu)先級(jí)都一樣，根據(jù)CFS調(diào)度算法，會(huì)平均分配時(shí)間片，不會(huì)讓其中一個(gè)線程獨(dú)占CPU。結(jié)果為多個(gè)線程間輪流調(diào)度，消耗掉了所有的cpu。。
另一個(gè)問(wèn)題：為什么這種情況下，內(nèi)核沒(méi)有檢測(cè)到softlockup？
因?yàn)闃I(yè)務(wù)進(jìn)程的優(yōu)先級(jí)不高，不會(huì)影響watchdog內(nèi)核線程（更高優(yōu)先級(jí)的實(shí)時(shí)線程）的調(diào)度，所以不會(huì)產(chǎn)生softlockup的情況。
再一個(gè)問(wèn)題：為什么每次查看線程堆棧時(shí)，總是阻塞在retint_careful，而不是其它地方？
因?yàn)檫@里（中斷返回的時(shí)候）正是調(diào)度的時(shí)機(jī)點(diǎn)，在其它時(shí)間點(diǎn)不能發(fā)生調(diào)度（不考慮其它情況~），而我們查看線程堆棧的行為，也必須依賴于進(jìn)程調(diào)度，所以我們每次查看堆棧時(shí)，正是查看堆棧的進(jìn)程（cat命令）得到調(diào)度的時(shí)候，這時(shí)正是中斷返回的時(shí)候，所以正好看到的阻塞點(diǎn)為retint_careful。
4）用戶態(tài)分析
從上面的分析看，推測(cè)應(yīng)該是用戶態(tài)發(fā)生了死鎖。
用戶態(tài)確認(rèn)方法：
部署debug信息，然后gdb attach相關(guān)進(jìn)程，確認(rèn)堆棧，并結(jié)合代碼邏輯分析。
最終確認(rèn)該問(wèn)題確為用戶態(tài)進(jìn)程中產(chǎn)生了死循環(huán)。
關(guān)于linux處理閏秒死鎖的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開(kāi)通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過(guò)10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開(kāi)發(fā)經(jīng)驗(yàn)。專業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
當(dāng)前名稱：Linux如何應(yīng)對(duì)閏秒導(dǎo)致的死鎖問(wèn)題？(linux處理閏秒死鎖)
本文URL：http://fisionsoft.com.cn/article/dhgijoi.html
