追蹤將服務(wù)器CPU耗光的兇手!

前面我們討論系統(tǒng)調(diào)用的時(shí)候結(jié)論是耗時(shí)200ns-15us不等。不過我今天說的我的這個(gè)遭遇可能會(huì)讓你進(jìn)一步認(rèn)識(shí)系統(tǒng)調(diào)用的真正開銷。在本節(jié)里你會(huì)看到一個(gè)耗時(shí)2.5ms的connect系統(tǒng)調(diào)用，注意是毫秒,相當(dāng)于2500us！

問題描述

當(dāng)時(shí)是我的一個(gè)線上云控接口，是nginx+lua寫的。正常情況下，單虛機(jī)8核8G可以抗每秒2000左右的QPS，負(fù)載還比較健康。但是該服務(wù)近期開始出現(xiàn)一些500狀態(tài)的請(qǐng)求了，監(jiān)控時(shí)不時(shí)會(huì)出現(xiàn)報(bào)警。通過sar -u查看峰值時(shí)cpu余量只剩下了20-30%。

圖3.jpg

第一步、迅速鎖定嫌疑人

top命令查看cpu使用，通過top命令發(fā)現(xiàn)峰值的時(shí)候cpu確實(shí)消耗的比較多，idle只有20-30%左右。在使用的cpu里，軟中斷的占比也比較高，1/3左右。
再通過cat /proc/softirqs查看到軟中斷是都是網(wǎng)絡(luò)IO產(chǎn)生的NET_TX，NET_RX，和時(shí)鐘TIMER。
既然軟中斷這個(gè)賊人吃掉了我這么多的CPU時(shí)間，所以案件的嫌疑人就這么初步被我鎖定了。

處理，那既然是NET_TX，NET_RX和TIMER都高，那咱就挑可以削減的功能砍一砍唄。

  • 1.砍掉多余的gettimeofday系統(tǒng)調(diào)用
  • 2.每個(gè)請(qǐng)求砍掉一次非必須Redis訪問，只留了必要的。

結(jié)果：峰值的cpu余量從確實(shí)多出來一些了。報(bào)警頻率確實(shí)下來了，但是還是偶爾會(huì)有零星的報(bào)警?？梢娫撓右扇瞬⒎侵鞣?。。

第二步、干掉一大片，真兇在其中

接著查看網(wǎng)絡(luò)連接的情況ss -n -t -a發(fā)現(xiàn)，ESTABLISH狀態(tài)的鏈接不是很多，但是TIME-WAIT有11W多。繼續(xù)研究發(fā)現(xiàn)針對(duì)..*.122:6390的TIME-WAIT已經(jīng)超過了3W。所以端口有限。原來呀，上一步執(zhí)行時(shí)只干掉了連接上的數(shù)據(jù)請(qǐng)求，但是tcp握手請(qǐng)求仍然存在。

處理：徹底干掉了針對(duì)..*.122:6390的網(wǎng)絡(luò)連接請(qǐng)求，只保留了必須保留的邏輯。
結(jié)果：?jiǎn)栴}徹底解決。sar -u查看cpu的idle余量竟然達(dá)到了90%多。

Tips：?jiǎn)闻_(tái)機(jī)器如果作為TCP的客戶端，有如下限制

  1. ESTABLISH狀態(tài)的連接只能有ip_local_port_range范圍內(nèi)的個(gè)數(shù)。
  2. 只有針對(duì)特定ip，特定port的TIME-WAIT過多，超過或接近ip_local_port_range，再新建立連接可能會(huì)出現(xiàn)無端口可用的情況。（ 總的TIME-WAIT過多并不一定有問題 ）

沒想到一個(gè)簡(jiǎn)單砍掉一個(gè)對(duì)redis server的tcp連接，能把cpu優(yōu)化到這么多。大大出乎意料，而且也想不明白。 根據(jù)我之前的性能測(cè)試經(jīng)驗(yàn)，每個(gè)tcp連接的建立大約只需要消耗36usec的cpu時(shí)間。我們來估算一下：

當(dāng)時(shí)server的qps大約在2000左右，假設(shè)是均勻分布的，則8個(gè)核每個(gè)核每秒只需要處理250個(gè)請(qǐng)求。也就是說每秒一條tcp連接需要消耗的cpu時(shí)間為：250*36usec = 9ms.

也就是說，正常來講砍掉這些握手開銷只能節(jié)約1%左右的cpu，不至于有這么大的提升。（即使我上面的估算只考慮了建立連接，沒有統(tǒng)計(jì)釋放連接的cpu開銷，但是連接釋放cpu開銷也和建立連接差不多。）

總之，這一步確實(shí)解決了問題，但是代價(jià)是犧牲了一個(gè)業(yè)務(wù)邏輯。

最終、審出真兇，真相大白于天下

我在某一臺(tái)機(jī)器上把老的有問題的代碼回滾了回來，恢復(fù)問題現(xiàn)場(chǎng)。然后只修改一下ip_local_port_range。 然后請(qǐng)出了strace這個(gè)命令。
通過strace -c 統(tǒng)計(jì)到對(duì)于所有系統(tǒng)調(diào)用的開銷匯總。 結(jié)果我們發(fā)現(xiàn)了connect系統(tǒng)調(diào)用這個(gè)二貨，在正常的機(jī)器上只需要22us左右，在有問題的機(jī)器上竟然花掉來 2500us，上漲了100倍。我們用strace -c $PID查看一下出問題時(shí)和正常時(shí)的connect系統(tǒng)調(diào)用耗時(shí)對(duì)比：

圖1.png

<centor>圖1：正常情況下</centor>

圖2.png

<centor>圖2：出問題時(shí)</centor>

然后回想起了..*.122:6390的TIME-WAIT已經(jīng)超過了3W，會(huì)不會(huì)TIME_WAIT占用了太多端口導(dǎo)致端口不足呢。因此查看端口內(nèi)核參數(shù)配置：

# sysctl -a | grep ip_local_port_range
net.ipv4.ip_local_port_range = 32768    65000

果然發(fā)現(xiàn)該機(jī)器上的端口范圍只開了3W多個(gè)，也就是說端口已經(jīng)幾乎快用滿了。那就提高端口可用數(shù)量：

# vim /etc/sysctl.conf
net.ipv4.ip_local_port_range = 10000 65000

connect系統(tǒng)調(diào)用恢復(fù)理性狀態(tài)，整體服務(wù)器的CPU使用率非常健康。

問題的根本原因是建立TCP連接使用的端口數(shù)量上（ip_local_port_range）不充裕，導(dǎo)致connect系統(tǒng)調(diào)用開銷上漲了將近100倍！

后來我們的一位開發(fā)同學(xué)幫忙翻到了connect系統(tǒng)調(diào)用里的一段源碼

int inet_hash_connect(struct inet_timewait_death_row *death_row,
               struct sock *sk)
{
    return __inet_hash_connect(death_row, sk, inet_sk_port_offset(sk),
            __inet_check_established, __inet_hash_nolisten);
}

int __inet_hash_connect(struct inet_timewait_death_row *death_row,
                struct sock *sk, u32 port_offset,
                int (*check_established)(struct inet_timewait_death_row *,
                        struct sock *, __u16, struct inet_timewait_sock **),
                int (*hash)(struct sock *sk, struct inet_timewait_sock *twp))
{
        struct inet_hashinfo *hinfo = death_row->hashinfo;
        const unsigned short snum = inet_sk(sk)->inet_num;
        struct inet_bind_hashbucket *head;
        struct inet_bind_bucket *tb;
        int ret;
        struct net *net = sock_net(sk);
        int twrefcnt = 1;

        if (!snum) {
                int i, remaining, low, high, port;
                static u32 hint;
                u32 offset = hint + port_offset;
                struct inet_timewait_sock *tw = NULL;

                inet_get_local_port_range(&low, &high);
                remaining = (high - low) + 1;

                local_bh_disable();
                for (i = 1; i <= remaining; i++) {
                        port = low + (i + offset) % remaining;
                        if (inet_is_reserved_local_port(port))
                                continue;
                        ......
        }
}

static inline u32 inet_sk_port_offset(const struct sock *sk)
{
        const struct inet_sock *inet = inet_sk(sk);  
        return secure_ipv4_port_ephemeral(inet->inet_rcv_saddr,  
                                          inet->inet_daddr,  
                                          inet->inet_dport);  
}

從上面源代碼可見，臨時(shí)端口選擇過程是生成一個(gè)隨機(jī)數(shù)，利用隨機(jī)數(shù)在ip_local_port_range范圍內(nèi)取值，如果取到的值在ip_local_reserved_ports范圍內(nèi) ，那就再依次取下一個(gè)值，直到不在ip_local_reserved_ports范圍內(nèi)為止。原來臨時(shí)端口竟然是隨機(jī)撞。出。來。的。。 也就是說假如就有range里配置了5W個(gè)端口可以用，已經(jīng)使用掉了49999個(gè)。那么新建立連接的時(shí)候，可能需要調(diào)用這個(gè)隨機(jī)函數(shù)5W次才能撞到這個(gè)沒用的端口身上。

所以請(qǐng)記得要保證你可用臨時(shí)端口的充裕，避免你的connect系統(tǒng)調(diào)用進(jìn)入SB模式。正常端口充足的時(shí)候，只需要22usec。但是一旦出現(xiàn)端口緊張，則一次系統(tǒng)調(diào)用耗時(shí)會(huì)上升到2.5ms，整整多出100倍。這個(gè)開銷比正常tcp連接的建立吃掉的cpu時(shí)間（每個(gè)30usec左右）的開銷要大的多。

解決TIME_WAIT的辦法除了放寬端口數(shù)量限制外，還可以考慮設(shè)置net.ipv4.tcp_tw_recycle和net.ipv4.tcp_tw_reuse這兩個(gè)參數(shù)，避免端口長(zhǎng)時(shí)間保守地等待2MSL時(shí)間。

歡迎關(guān)注個(gè)人公眾號(hào)“開發(fā)內(nèi)功修煉”，打通理論與實(shí)踐的任督二脈

參考文獻(xiàn)

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容