導(dǎo)讀 | 第27屆國(guó)際計(jì)量大會(huì)宣布最遲不晚于2035年取消引入閏秒，這一消息引起轟動(dòng)。上一次閏秒產(chǎn)生，對(duì)Reddit、Mozilla、FourSquare等都產(chǎn)生了一定的問(wèn)題，其中Reddit宕機(jī)時(shí)間超過(guò)1個(gè)半小時(shí)！本欄目特邀騰訊后臺(tái)開發(fā)工程師陶松橋，帶你是深入了解閏秒的來(lái)源及其影響，并介紹各類系統(tǒng)常見的閏秒處理方法，其中會(huì)分享TencentOS Server 操作系統(tǒng)的解決方案。
閏秒從何而來(lái)世界上有幾種計(jì)量時(shí)間的方式：世界時(shí)（UT1）：是一種天文計(jì)量的方式，天文學(xué)家通過(guò)觀測(cè)地球的自轉(zhuǎn)，并將自轉(zhuǎn)一周的時(shí)間（一天）等分為86400份，每份為一秒，受潮汐等因素的影響，地球自轉(zhuǎn)一周的時(shí)間并不是恒定的，這也是造成閏秒現(xiàn)象的直接原因。原子時(shí)（TAI）：由于上面描述的世界時(shí)并不穩(wěn)定，物理學(xué)家用更為穩(wěn)定的量子計(jì)量的方式來(lái)統(tǒng)計(jì)時(shí)間，1967年，國(guó)際計(jì)量大會(huì)用銫133（Cs133）原子基態(tài)的兩個(gè)超精細(xì)能級(jí)之間的躍遷所對(duì)應(yīng)輻射的9192631770個(gè)周期所持續(xù)的時(shí)間定義為1秒，這個(gè)是目前最精確的時(shí)間計(jì)量方式，其誤差為1400000年一秒，基本可忽略不計(jì)。協(xié)調(diào)世界時(shí)（UTC）：又稱世界標(biāo)準(zhǔn)時(shí)間或世界協(xié)調(diào)時(shí)間，UTC以TAI為基礎(chǔ)，又要兼顧UT1，當(dāng)UTC，和UT1之間的偏差接近1秒時(shí)，國(guó)際地球自轉(zhuǎn)和參考系服務(wù)（IERS）會(huì)提前6個(gè)月公布下一次閏秒的時(shí)間。我們將世界絕大多數(shù)地方時(shí)區(qū)的基本時(shí)間稱為協(xié)調(diào)世界時(shí)，即 UTC。它源自分布在世界一些國(guó)家的大量原子時(shí)鐘。地球的自轉(zhuǎn)并不是非常恒定的，有時(shí)會(huì)有一些變化，平均自轉(zhuǎn)速度會(huì)緩慢下降。這就是為什么會(huì)在 UTC 時(shí)標(biāo)中插入所謂閏秒，它們可將 UTC 時(shí)間進(jìn)程調(diào)整到真實(shí)地球自轉(zhuǎn)時(shí)間。為什么會(huì)多出這一秒呢？它的存在是因?yàn)闆Q定晝夜更替的地球繞軸自轉(zhuǎn)會(huì)在很長(zhǎng)的一段時(shí)間內(nèi)慢下來(lái)，主要是由月亮-太陽(yáng)引力造成。另外，地球也受其內(nèi)部（地核、地幔）和外部（氣候、海洋）構(gòu)成影響。目前，時(shí)間主要由分屬幾個(gè)國(guó)家的 250臺(tái)原子時(shí)鐘測(cè)量，這些原子鐘是通過(guò)測(cè)量原子的能量轉(zhuǎn)換水平工作。使用這些時(shí)鐘計(jì)算 UTC，同時(shí)因?yàn)檫@個(gè)時(shí)間測(cè)量原理周期性地與地球不同步，因此必須使用閏秒進(jìn)行校正。另外，我們必須考慮到現(xiàn)在的一天比 1820年的一天要長(zhǎng) 2 毫秒。不出所料，地球自轉(zhuǎn)慢慢就與 UTC 不同步了。國(guó)際地球自轉(zhuǎn)服務(wù)局IERS 測(cè)量的是真實(shí)地球自轉(zhuǎn)，并決定何時(shí)插入閏秒。插入閏秒一般總是在某個(gè)月的最后一天進(jìn)行，首選六月或十二月的 UTC 午夜時(shí)間。過(guò)去每次添加閏秒都是在六月或十二月進(jìn)行。是否添加閏秒的聲明，會(huì)由 IERS 在其Bulletin C 中發(fā)布。目前，在可能添加閏秒日期前半年會(huì)公布 Bulletin C 。因?yàn)殚c秒是在全世界同時(shí)插入，插入閏秒的本地（民用）時(shí)間取決于本地時(shí)間與 UTC 之間的偏差，例如：2015年7月1日發(fā)生閏秒時(shí)，在時(shí)區(qū) UTC+8h（北京時(shí)間）中，閏秒會(huì)在時(shí)鐘顯示午夜后 8 小時(shí)的時(shí)候插入。閏秒時(shí)計(jì)算北京時(shí)間的標(biāo)準(zhǔn)方法為：如果系統(tǒng)時(shí)鐘采用國(guó)際原子時(shí)（TAI），并使用正確的時(shí)區(qū)，那么就會(huì)列出 23:59:60。但因?yàn)樵?Unix 的 UTC 使用中不存在 23:59:60，Linux內(nèi)核會(huì)采用倒回一秒的方法在0:00 UTC 后第一次時(shí)鐘更新時(shí)插入閏秒。在本地時(shí)間計(jì)時(shí)中，根據(jù)不同的時(shí)區(qū)偏差，比如 UTC+8h，在TencentOS Server系統(tǒng)中，您會(huì)觀察到以下現(xiàn)象：2015-07-01 07.59.572015-07-01 07.59.582015-07-01 07.59.592015-07-01 07.59.60 <-- 閏秒2015-07-01 08.00.002015-07-01 08.00.012015-07-01 08.00.02
(相關(guān)資料圖)
IERS 確定閏秒后，一些時(shí)間傳播服務(wù)還會(huì)發(fā)布閏秒通知。這包括德國(guó)長(zhǎng)波發(fā)射機(jī) DCF77 和衛(wèi)星巡航系統(tǒng) GPS 示例。因此，可解碼從那些系統(tǒng)獲取信號(hào)的接收器也可以解碼閏秒通知。如果在所應(yīng)用協(xié)議中包含閏秒信息（例如接收器傳送的時(shí)間字符串），則從那些接收器讀取時(shí)間的應(yīng)用程序也可以確定閏秒通知。請(qǐng)注意，時(shí)間代碼接收器只能將閏秒通知轉(zhuǎn)發(fā)到應(yīng)用程序，同時(shí)正確計(jì)時(shí)。正確處理閏秒是應(yīng)用程序和（/或）操作系統(tǒng)的任務(wù)。從1972年到2020年，平均每21個(gè)月就插入一次閏秒。然而，間隔是非常不規(guī)則的，而且明顯在增加。在1999年1月1日至2004年12月31日的六年中沒有閏秒，但在1972-1979年的八年中有九個(gè)閏秒。自1972年協(xié)調(diào)世界時(shí)正式使用至今，全球已經(jīng)實(shí)施了27次正閏秒調(diào)整，最近一次的閏秒調(diào)整是格林尼治時(shí)間2016年12月31日。從協(xié)調(diào)世界時(shí)正式使用以來(lái)，地球自轉(zhuǎn)一直處于不斷減慢的趨勢(shì)，因此迄今為止的閏秒都是正閏秒。但相關(guān)科研發(fā)現(xiàn)，自2020年年中以來(lái)，地球自轉(zhuǎn)速率呈現(xiàn)加快趨勢(shì)，這意味著未來(lái)也可能會(huì)出現(xiàn)負(fù)閏秒。目前TAI與UTC的秒差為37：2015-07-01 07:59:58.0002015-07-01 07:59:58.5002015-07-01 07:59:59.0002015-07-01 07:59:59.5002015-07-01 08:00:00.000 <-- 插入閏秒2015-07-01 07:59:59.0002015-07-01 07:59:59.5002015-07-01 08:00:00.0002015-07-01 08:00:00.500
# Value of TAI-UTC in second valid beetween the initial value until# the epoch given on the next line. The last line reads that NO# leap second was introduced since the corresponding date # Updated through IERS Bulletin 64 issued in July 2022# ## File expires on 28 June 2023### MJD Date TAI-UTC (s)# day month year# --- -------------- ------ # 41317.0 1 1 1972 10 41499.0 1 7 1972 11 41683.0 1 1 1973 12 42048.0 1 1 1974 13 42413.0 1 1 1975 14 42778.0 1 1 1976 15 43144.0 1 1 1977 16 43509.0 1 1 1978 17 43874.0 1 1 1979 18 44239.0 1 1 1980 19 44786.0 1 7 1981 20 45151.0 1 7 1982 21 45516.0 1 7 1983 22 46247.0 1 7 1985 23 47161.0 1 1 1988 24 47892.0 1 1 1990 25 48257.0 1 1 1991 26 48804.0 1 7 1992 27 49169.0 1 7 1993 28 49534.0 1 7 1994 29 50083.0 1 1 1996 30 50630.0 1 7 1997 31 51179.0 1 1 1999 32 53736.0 1 1 2006 33 54832.0 1 1 2009 34 56109.0 1 7 2012 35 57204.0 1 7 2015 36 57754.0 1 1 2017 37閏秒處理方案1）運(yùn)行NTP的系統(tǒng)系統(tǒng)如果使用 NTP（網(wǎng)絡(luò)時(shí)間協(xié)議）守護(hù)進(jìn)程（ntpd）將其本地計(jì)時(shí)與 NTP 服務(wù)器同步，則都應(yīng)自動(dòng)進(jìn)行閏秒調(diào)整。進(jìn)行閏秒調(diào)整的前一天，NTP 服務(wù)器應(yīng)通知其客戶端第二天的 23:59:59 UTC 會(huì)發(fā)生發(fā)生閏秒，Linux 內(nèi)核應(yīng)通過(guò)兩次顯示第 60秒或徹底刪除它，以便添加或者刪除額外一秒。因此，在閏秒調(diào)整期間，運(yùn)行 NTP 的系統(tǒng)應(yīng)有如下計(jì)時(shí)顯示：
2015-06-30 23:59:59 UTC2015-06-30 23:59:59 UTC2015-06-30 00:00:00 UTC發(fā)生閏秒時(shí)，內(nèi)核會(huì)在系統(tǒng) log 中寫入信息：
Jul 1 07:59:59 TENCENT64 kernel: [579201.951291] Clock: inserting leap second 23:59:60 UTC使用ntpdate命令方式，與ntp服務(wù)器進(jìn)行時(shí)間同步的系統(tǒng)，將不會(huì)通過(guò)ntp服務(wù)器接收到閏秒通知，而是在系統(tǒng)管理員指定的時(shí)刻與ntp服務(wù)器進(jìn)行時(shí)間同步。例如，系統(tǒng)管理員設(shè)定每小時(shí)的第52分與ntp服務(wù)器進(jìn)行時(shí)間同步，那么在7月1日08:00 CST到09:52之間，系統(tǒng)時(shí)間與ntp服務(wù)器時(shí)間會(huì)相差1秒（快1秒）。2）運(yùn)行PTP的系統(tǒng)PTP（精確時(shí)間協(xié)議）中交換的時(shí)間戳通常采用不包含閏秒的TAI（國(guó)際原子時(shí)）；但 ptp4l 和 phc2sys 將設(shè)置內(nèi)核標(biāo)簽，插入閏秒以便系統(tǒng)時(shí)鐘繼續(xù)以 UTC 運(yùn)行。然后該內(nèi)核就可以正常插入閏秒。3）未運(yùn)行NTP或者PTP的系統(tǒng)默認(rèn)情況下，不使用 NTP 或者 PTP 同步其計(jì)時(shí)的 Linux 系統(tǒng)不會(huì)修正閏秒，且這些系統(tǒng)報(bào)告的時(shí)間與修正閏秒后的 UTC 時(shí)間有一秒鐘的差別。閏秒發(fā)生后應(yīng)手動(dòng)重置時(shí)鐘。您還可以將 tzdata 更新至最新版本，將/usr/share/zoneinfo/right 目錄層級(jí)中的正確文件復(fù)制到/etc/localtime，并將時(shí)鐘重置到正確的本地時(shí)間，以便將這些系統(tǒng)配置可正確報(bào)告時(shí)間。/usr/share/zoneinfo/right 中的文件包含自該世紀(jì)開始，從 1970年 1 月 1 日00:00:00 UTC 發(fā)生的所有閏秒修正的本地時(shí)間信息。/usr/share/zoneinfo 中的其他時(shí)區(qū)文件未添加閏秒修正。從1972年至今，共添加了 27次閏秒。例如：如果某個(gè)系統(tǒng)位于中國(guó)時(shí)區(qū)，您可以將其重新配置為通過(guò)運(yùn)行以下命令報(bào)告閏秒修正時(shí)間，
例如在TS2系統(tǒng)中，tzdata包的版本為tzdata-2015a-1.tl2.noarch，執(zhí)行完上述拷貝后，則會(huì)在閏秒發(fā)生時(shí)間2015年7月1日8點(diǎn)自動(dòng)插入閏秒。4）windows系統(tǒng)早期的Windows版本(Win10版本以前)時(shí)間服務(wù)并不表示 Leap 指標(biāo)的值，當(dāng) Windows 時(shí)間服務(wù)接收到的數(shù)據(jù)包，包括閏秒。因此，閏秒發(fā)生后，正在運(yùn)行 Windows 時(shí)間服務(wù)的 NTP 客戶端會(huì)比實(shí)際時(shí)間快一秒。這種時(shí)間差異在下次同步時(shí)解決。從 Windows 10 Redstone 5 和 Windows Server 2019 起，微軟的操作系統(tǒng)能以更精確、UTC 兼容和可追蹤的方式處理閏秒。不過(guò)從2017年至今，沒有發(fā)生過(guò)閏秒了。歷史影響對(duì)于日常生活而言，正常的上班、下班、工作、學(xué)習(xí)，生命中偏差的這一秒無(wú)關(guān)痛癢。然而閏秒對(duì)于精確要求時(shí)間的行業(yè)如航空、航天、軍工等，會(huì)產(chǎn)生較大影響。對(duì)于服務(wù)器清一色linux系統(tǒng)的互聯(lián)網(wǎng)行業(yè)而言，閏秒可能會(huì)造成機(jī)器cpu突然增高，機(jī)器宕機(jī)、對(duì)應(yīng)的服務(wù)掛掉。隨著linux的普遍使用，閏秒的影響也被越來(lái)越多的被關(guān)注。歷史上，因?yàn)閘inux內(nèi)核的一些問(wèn)題，閏秒對(duì)系統(tǒng)造成多次影響。比如CPU利用率高會(huì)給生產(chǎn)環(huán)境帶了不少挑戰(zhàn)。2012年實(shí)施閏秒時(shí)，國(guó)外不少知名網(wǎng)站出現(xiàn)了臨時(shí)服務(wù)中斷。當(dāng)2015年閏秒再度來(lái)臨時(shí)，工程師們修復(fù)了部分2012年出現(xiàn)的問(wèn)題，但卻東窗事發(fā)——發(fā)現(xiàn)了新的問(wèn)題。后續(xù)亦是如此。閏秒讓互聯(lián)網(wǎng)企業(yè)如鯁在喉。1） linux-2.6.22以前內(nèi)核版本的閏秒死鎖07年的commit：http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b;hp=872aad45d6174570dd2e1defc3efee50f2cfcc72每次時(shí)鐘中斷觸發(fā)時(shí)會(huì)調(diào)用 tick_do_update_jiffies64 更新 jiffies 的值。因此在更新前對(duì) xtime_lock 加了寫鎖。閏秒產(chǎn)生時(shí)，開發(fā)者需要修正jiffies 的值。在 tick_do_update_jiffies64 里面最終會(huì)調(diào)用到 second_overflow 這個(gè)函數(shù)，以處理潤(rùn)秒。在函數(shù) second_overflow 里面，處理潤(rùn)秒的增加和減少前都調(diào)用了一個(gè) clock_was_set 函數(shù)。該函數(shù)內(nèi)部，請(qǐng)求了 xtime_lock 的讀鎖。此時(shí)，與先前的寫鎖發(fā)生死鎖。該patch在linux內(nèi)核版本2.6.22中引入，所以只有2.6.22內(nèi)核之前的系統(tǒng)可會(huì)出現(xiàn)該問(wèn)題，也就是影響sles10和centos5.5系統(tǒng)。在sles10和centos5.5中，clock_was_set()因不支持高精度時(shí)鐘而被定義為空，所以不造成影響。2）linux-2.6.25到2.6.27內(nèi)核版本的系統(tǒng)死鎖Bug 479765 - Leap second message can hang the kernel 描述了leap second會(huì)對(duì)系統(tǒng)產(chǎn)生影響的原因：當(dāng)一個(gè)leap second被插入或刪除時(shí)，內(nèi)核會(huì)打印一條相關(guān)信息：[69596.647516] Clock: inserting leap second 23:59:60 UTC而該信息的打印會(huì)因xtime_lock而造成系統(tǒng)死鎖。下面是2.6.26內(nèi)核下該問(wèn)題出現(xiàn)時(shí)的棧信息(this is with Fedora 8 andkernel kernel-2.6.26.6-49.fc8.x86_64)：cp /usr/share/zoneinfo/right/Asia/Shanghai /etc/localtime
#0 ktime_get_ts (ts=0xffffffff8158bb30) at include/asm/processor.h:691#1 0xffffffff8104c09a in ktime_get () at kernel/hrtimer.c:59#2 0xffffffff8102a39a in hrtick_start_fair (rq=0xffff810009013880, p=從上面的棧信息我們可以發(fā)現(xiàn)：該問(wèn)題的出現(xiàn)原因是當(dāng)對(duì)leap second進(jìn)行操作（插入或刪除）之前，已經(jīng)獲取了xtime_lock鎖；而之后在調(diào)用printk()打印日志信息時(shí)，printk()中會(huì)嘗試喚醒klogd內(nèi)核線程，在喚醒過(guò)程中會(huì)調(diào)用到公平調(diào)度類的相關(guān)函數(shù)，其中會(huì)調(diào)用ktime_get()獲取時(shí)間信息，其中會(huì)再次嘗試獲取xtime_lock鎖，從而造成死鎖。該現(xiàn)象部分因?yàn)閔rtick_start_fair()函數(shù)的引入。是由commit 8f4d37ec (high-res preemption tick)引發(fā)，這大概在2.6.25版本引入。但是在2.6.25之前的內(nèi)核，不會(huì)發(fā)生這個(gè)死鎖。2.6.28版本引入了commit b845b517。printk()中的wake_up_klogd()不會(huì)直接wake_up klogd()，也就不會(huì)觸發(fā)后續(xù)的xtime_lock，最終避免了死鎖的發(fā)生。所以，該原因引起的系統(tǒng)死鎖只可能發(fā)生在linux內(nèi)核2.6.25到2.6.27版本下。Sles11使用2.6.27內(nèi)核，屬于比較危險(xiǎn)的部分內(nèi)核。但是Novell聲稱已經(jīng)引入了commit b845b517b5e3706a3729f6ea83b88ab85f0725b0，因而不存在該問(wèn)題，而且?guī)讉€(gè)小時(shí)的實(shí)驗(yàn)后系統(tǒng)仍然正常。此問(wèn)題影響的版本還有 RHEL4:kernel-2.6.9.89.EL之前的版本，RHEL5.3：kernel-2.6.18-128.37.1.el5之前的版本?，F(xiàn)網(wǎng)centos5.5使用的內(nèi)核版本是2.6.18-194.el5，其不受影響。3）linux-3.4內(nèi)核版本的系統(tǒng)活鎖08年的commit中為了解決之前遇到的leap second問(wèn)題而將對(duì)leap second的處理從second_overflow()中獨(dú)立出來(lái)，使用定時(shí)器來(lái)完成此工作。但是12年的commit認(rèn)為該patch存在如下可能的livelock場(chǎng)景：) at kernel/sched.c:1064#3 0xffffffff8102decc in enqueue_task_fair (rq=0xffff810009013880, p=0xffff81003fb02d40, wakeup=1) at kernel/sched_fair.c:863#4 0xffffffff81029a08 in enqueue_task (rq=0xffffffff8158bb30, p=0xffff81003b8ac418, wakeup=-994836480) at kernel/sched.c:1550#5 0xffffffff81029a39 in activate_task (rq=0xffff810009013880, p=0xffff81003b8ac418, wakeup=20045) at kernel/sched.c:1614#6 0xffffffff8102be38 in try_to_wake_up (p=0xffff81003fb02d40, state= , sync=0) at kernel/sched.c:2173#7 0xffffffff8102be9c in default_wake_function (curr= , mode=998949912, sync=20045, key=0x4c4b40000) at kernel/sched.c:4366#8 0xffffffff810492ed in autoremove_wake_function (wait=0xffffffff8158bb30, mode=998949912, sync=20045, key=0x4c4b40000) at kernel/wait.c:132#9 0xffffffff810296a2 in __wake_up_common (q=0xffffffff813d3180, mode=1, nr_exclusive=1, sync=0, key=0x0) at kernel/sched.c:4387#10 0xffffffff8102b97b in __wake_up (q=0xffffffff813d3180, mode=1, nr_exclusive=1, key=0x0) at kernel/sched.c:4406#11 0xffffffff8103692f in wake_up_klogd () at kernel/printk.c:1005#12 0xffffffff81036abb in release_console_sem () at kernel/printk.c:1051#13 0xffffffff81036fd1 in vprintk (fmt= , args= ) at kernel/printk.c:789#14 0xffffffff81037081 in printk ( fmt=0xffffffff8158bb30 "yj$\201????\2008\001\t") at kernel/printk.c:613#15 0xffffffff8104ec16 in ntp_leap_second (timer= ) at kernel/time/ntp.c:143#16 0xffffffff8104b7a6 in run_hrtimer_pending (cpu_base=0xffff81000900f740) at kernel/hrtimer.c:1204#17 0xffffffff8104b86a in run_hrtimer_softirq (h= ) at kernel/hrtimer.c:1355#18 0xffffffff8103b31f in __do_softirq () at kernel/softirq.c:234#19 0xffffffff8100d52c in call_softirq () at include/asm/current_64.h:10#20 0xffffffff8100ed5e in do_softirq () at arch/x86/kernel/irq_64.c:262#21 0xffffffff8103b280 in irq_exit () at kernel/softirq.c:310#22 0xffffffff8101b0fe in smp_apic_timer_interrupt (regs= ) at arch/x86/kernel/apic_64.c:514#23 0xffffffff8100cf52 in apic_timer_interrupt () at include/asm/current_64.h:10#24 0xffff81003b9d5a90 in ?? ()#25 0x0000000000000000 in ?? ()
CPU 0 CPU 1do_adjtimex()spin_lock_irq(&ntp_lock);process_adjtimex_modes(); timer_interrupt()process_adj_status(); do_timer()ntp_start_leap_timer(); write_lock(&xtime_lock);hrtimer_start(); update_wall_time();hrtimer_reprogram(); ntp_tick_length()tick_program_event() spin_lock(&ntp_lock);clockevents_program_event()ktime_get()seq = req_seqbegin(xtime_lock);問(wèn)題在于，引入ntp_lock的commit（http://patches.linaro.org/5122/）是在3.4內(nèi)核版本，且在3.4內(nèi)核得到了修復(fù)。所以此問(wèn)題對(duì)3.4以前和以后的內(nèi)核無(wú)影響。08年的commit：https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7dffa3c673fbcf835cd7be80bb4aec8ad3f5116812年的commit：https://lkml.org/lkml/2012/3/15/6164）linux-2.6.32內(nèi)核插入閏秒可能出現(xiàn)高CPU消耗2012年的閏秒插入當(dāng)時(shí)導(dǎo)致了一些互聯(lián)網(wǎng)公司的服務(wù)器高cpu消耗，其問(wèn)題根源在以下網(wǎng)址得到了闡述：https://lkml.org/lkml/2012/7/1/203leap-a-day.c為一個(gè)小測(cè)試程序，編譯后加-s參數(shù)運(yùn)行，可每10秒插入或者刪除一個(gè)閏秒，用戶可自行下載編譯測(cè)試。2015年7月1日的閏秒將會(huì)出現(xiàn)以下現(xiàn)象：
Setting time to Wed Jul 1 07:59:50 2015Scheduling leap second for Wed Jul 1 08:00:00 2015Wed Jul 1 07:59:57 2015 + 98 us (3883) TIME_INSWed Jul 1 07:59:57 2015 + 500248 us (3883) TIME_INSWed Jul 1 07:59:58 2015 + 366 us (3883) TIME_INSWed Jul 1 07:59:58 2015 + 500483 us (3883) TIME_INSWed Jul 1 07:59:59 2015 + 598 us (3883) TIME_INSWed Jul 1 07:59:59 2015 + 500740 us (3883) TIME_INSWed Jul 1 07:59:59 2015 + 910 us (3883) TIME_OOPWed Jul 1 07:59:59 2015 + 501046 us (3883) TIME_OOPWed Jul 1 08:00:00 2015 + 1214 us (3884) TIME_WAITWed Jul 1 08:00:00 2015 + 501359 us (3884) TIME_WAITWed Jul 1 08:00:01 2015 + 1481 us (3884) TIME_WAITWed Jul 1 08:00:01 2015 + 501599 us (3884) TIME_WAITWed Jul 1 08:00:02 2015 + 1650 us (3884) TIME_WAIT我們測(cè)試后發(fā)現(xiàn)，在TS1.2發(fā)行版下，可出現(xiàn)“ERROR: hrtimer early expiration failure observed”提示。
/* Test for known hrtimer failure */void test_hrtimer_failure(void){ struct timespec now, target; clock_gettime(CLOCK_REALTIME, &now); target = timespec_add(now, NSEC_PER_SEC/2);clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &target, NULL); clock_gettime(CLOCK_REALTIME, &now); if (!in_order(target, now)){ printf("ERROR: hrtimer early expiration failure observed.\n"); }分析代碼可以發(fā)現(xiàn)：使用clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &target, NULL);這種定時(shí)器方式，在插入閏秒后，該定時(shí)器本應(yīng)該0.5秒到期，卻立刻到期。本質(zhì)原因是內(nèi)核中記錄時(shí)間的數(shù)據(jù)結(jié)構(gòu)中并沒有表達(dá)閏秒的地方,因此在增加閏秒時(shí)需要特別調(diào)整這些數(shù)據(jù)結(jié)構(gòu)。而很多定時(shí)器并不直接使用“絕對(duì)”時(shí)鐘而使用相對(duì)的時(shí)間間隔，這樣，在定時(shí)器代碼中就應(yīng)該對(duì)閏秒做額外的檢查。但問(wèn)題是這樣的檢查之前被刪掉。對(duì)于許多應(yīng)用來(lái)說(shuō)，定時(shí)器的一次提前觸發(fā)并不是什么問(wèn)題。但有些定時(shí)器則不然，他們會(huì)反復(fù)啟動(dòng)自己，這樣的后果就是它們反復(fù)地被快速喚醒，于是系統(tǒng)負(fù)載就出現(xiàn)了觀察到的尖峰現(xiàn)象。閏秒的插入沒有調(diào)用clock_was_set()，來(lái)提醒hrtimer子系統(tǒng)改變。定時(shí)器在插入閏秒后，其基準(zhǔn)比系統(tǒng)時(shí)間快一秒，因此會(huì)提前一秒到期。在觀察到cpu高消耗后，解決方法很簡(jiǎn)單，執(zhí)行下述命令即可：date -s "`date`"其原理就是date再設(shè)置一下當(dāng)前系統(tǒng)時(shí)間，clock_settime(CLOCK_REALTIME,&ts)會(huì)調(diào)用clock_was_set()。為了應(yīng)對(duì)ntpd同步可能出現(xiàn)的該問(wèn)題，我們?cè)?015年特意編寫了一個(gè)解決程序，該程序經(jīng)過(guò)編譯后可以添加到crontab任務(wù)：
58 7 1 7 * /data/solve_hrtimer_failure.o > /data/solve_hrtimer_failure.log 2>&1在7月1日7點(diǎn)58分開始，每隔100ms檢測(cè)閏秒是否插入了，當(dāng)插入閏秒后，該程序調(diào)用clock_settime函數(shù)，進(jìn)而修復(fù)了該問(wèn)題。取消閏秒1）為何取消閏秒對(duì)閏秒最為敏感的莫過(guò)于計(jì)算機(jī)相關(guān)領(lǐng)域。由于閏秒的出現(xiàn)沒有固定規(guī)律，對(duì)應(yīng)的時(shí)間調(diào)整無(wú)法從一開始就寫在計(jì)算機(jī)程序里。在萬(wàn)物互聯(lián)時(shí)代，很多領(lǐng)域都依托計(jì)算機(jī)網(wǎng)絡(luò)傳輸信息，實(shí)施閏秒也會(huì)影響航空、通信、金融及其他需要精準(zhǔn)對(duì)時(shí)的領(lǐng)域。今年7月Meta公司兩名工程師發(fā)文稱：“閏秒是一種弊大于利的冒險(xiǎn)做法，我們認(rèn)為現(xiàn)在是時(shí)候引入新技術(shù)來(lái)取代它了?！边@一表態(tài)引來(lái)各大公司稱道。2）取消閏秒的后續(xù)可能負(fù)責(zé)協(xié)調(diào)世界時(shí)的國(guó)際計(jì)量局（BIPM）表示，科學(xué)家和政府代表18日在法國(guó)舉行的一次會(huì)議上投票決定到2035年取消閏秒。BIPM時(shí)間部門負(fù)責(zé)人帕特里齊亞·塔維拉表示，這項(xiàng)“歷史性決定”將允許“秒數(shù)連續(xù)流動(dòng)，而不會(huì)出現(xiàn)目前由不規(guī)則閏秒造成的不連續(xù)性。閏秒是目前把世界時(shí)和國(guó)際原子時(shí)聯(lián)系起來(lái)的手段。由于世界時(shí)是基于地球自轉(zhuǎn)確定的，又稱天文時(shí)或太陽(yáng)時(shí)。沒有閏秒意味著人們使用的時(shí)間與地球自轉(zhuǎn)、太陽(yáng)位置不關(guān)聯(lián)，時(shí)間和天文學(xué)呈現(xiàn)割裂狀態(tài)。第27屆國(guó)際計(jì)量大會(huì)決議要求多機(jī)構(gòu)協(xié)商，提出一個(gè)可以將協(xié)調(diào)世界時(shí)持續(xù)至少百年的新方案并制定實(shí)施計(jì)劃，納入下一屆大會(huì)的決議草案中。根據(jù)決議，閏秒將暫時(shí)繼續(xù)正常添加。但到2035年，世界時(shí)和國(guó)際原子時(shí)之間的差異將被允許增長(zhǎng)到大于一秒的值。也許解決這個(gè)問(wèn)題的可能方法是讓世界時(shí)和國(guó)際原子時(shí)之間的差異增加到一分鐘，但專家估計(jì)調(diào)整時(shí)長(zhǎng)在50到100年之間。而有提議指出，無(wú)需在時(shí)鐘上增加閏分鐘，而是將某一天的最后一分鐘變?yōu)樾枰獌煞昼?；也有人建議停止校正，同時(shí)公布世界時(shí)和國(guó)際原子時(shí)之間不斷增長(zhǎng)的時(shí)刻差。
騰訊工程師技術(shù)干貨直達(dá)：
1、算法工程師深度解構(gòu)ChatGPT技術(shù)
2、10分鐘！從架構(gòu)視角讀懂K8s
3、探秘微信業(yè)務(wù)優(yōu)化：DDD從入門到實(shí)踐
4、祖?zhèn)鞔a重構(gòu)：從25萬(wàn)行到5萬(wàn)行的血淚史
Copyright © 2015-2022 亞洲導(dǎo)購(gòu)網(wǎng)版權(quán)所有 備案號(hào)：豫ICP備20022870號(hào)-9 聯(lián)系郵箱：553 138 779@qq.com
