前面我們討論系統(tǒng)調(diào)用的時候結(jié)論是耗時200ns-15us不等。不過我今天說的我的這個遭遇可能會讓你進(jìn)一步認(rèn)識系統(tǒng)調(diào)用的真正開銷。在本節(jié)里你會看到一個耗時2.5ms的connect系統(tǒng)調(diào)用，注意是毫秒,相當(dāng)于2500us！
問題描述
當(dāng)時是我的一個線上云控接口，是Nginx+lua寫的。正常情況下，單虛機(jī)8核8G可以抗每秒2000左右的QPS，負(fù)載還比較健康。但是該服務(wù)近期開始出現(xiàn)一些500狀態(tài)的請求了，監(jiān)控時不時會出現(xiàn)報(bào)警。通過sar -u查看峰值時cpu余量只剩下了20-30%。
圖3.jpg
第一步、迅速鎖定嫌疑人
top命令查看cpu使用，通過top命令發(fā)現(xiàn)峰值的時候cpu確實(shí)消耗的比較多，idle只有20-30%左右。在使用的cpu里，軟中斷的占比也比較高，1/3左右。
再通過cat /proc/softirqs查看到軟中斷是都是網(wǎng)絡(luò)IO產(chǎn)生的NET_TX，NET_RX，和時鐘TIMER。
既然軟中斷這個賊人吃掉了我這么多的CPU時間，所以案件的嫌疑人就這么初步被我鎖定了。
處理，那既然是NET_TX，NET_RX和TIMER都高，那咱就挑可以削減的功能砍一砍唄。
- 1.砍掉多余的gettimeofday系統(tǒng)調(diào)用
- 2.每個請求砍掉一次非必須redis訪問，只留了必要的。
結(jié)果：峰值的cpu余量從確實(shí)多出來一些了。報(bào)警頻率確實(shí)下來了，但是還是偶爾會有零星的報(bào)警。可見該嫌疑人并非主犯。。
第二步、干掉一大片，真兇在其中
接著查看網(wǎng)絡(luò)連接的情況ss -n -t -a發(fā)現(xiàn)，ESTABLISH狀態(tài)的鏈接不是很多，但是TIME-WAIT有11W多。繼續(xù)研究發(fā)現(xiàn)針對..*.122:6390的TIME-WAIT已經(jīng)超過了3W。所以端口有限。原來呀，上一步執(zhí)行時只干掉了連接上的數(shù)據(jù)請求，但是tcp握手請求仍然存在。
處理：徹底干掉了針對..*.122:6390的網(wǎng)絡(luò)連接請求，只保留了必須保留的邏輯。
結(jié)果：問題徹底解決。sar -u查看cpu的idle余量竟然達(dá)到了90%多。
Tips：單臺機(jī)器如果作為TCP的客戶端，有如下限制
- ESTABLISH狀態(tài)的連接只能有ip_local_port_range范圍內(nèi)的個數(shù)。
- 只有針對特定ip，特定port的TIME-WAIT過多，超過或接近ip_local_port_range，再新建立連接可能會出現(xiàn)無端口可用的情況。（ 總的TIME-WAIT過多并不一定有問題 ）
沒想到一個簡單砍掉一個對redis server的tcp連接，能把cpu優(yōu)化到這么多。大大出乎意料，而且也想不明白。 根據(jù)我之前的性能測試經(jīng)驗(yàn)，每個tcp連接的建立大約只需要消耗36usec的cpu時間。我們來估算一下：
當(dāng)時server的qps大約在2000左右，假設(shè)是均勻分布的，則8個核每個核每秒只需要處理250個請求。也就是說每秒一條tcp連接需要消耗的cpu時間為：250*36usec = 9ms.
也就是說，正常來講砍掉這些握手開銷只能節(jié)約1%左右的cpu，不至于有這么大的提升。（即使我上面的估算只考慮了建立連接，沒有統(tǒng)計(jì)釋放連接的cpu開銷，但是連接釋放cpu開銷也和建立連接差不多。）
總之，這一步確實(shí)解決了問題，但是代價(jià)是犧牲了一個業(yè)務(wù)邏輯。
最終、審出真兇，真相大白于天下
我在某一臺機(jī)器上把老的有問題的代碼回滾了回來，恢復(fù)問題現(xiàn)場。然后只修改一下ip_local_port_range。 然后請出了strace這個命令。
通過strace -c 統(tǒng)計(jì)到對于所有系統(tǒng)調(diào)用的開銷匯總。 結(jié)果我們發(fā)現(xiàn)了connect系統(tǒng)調(diào)用這個二貨，在正常的機(jī)器上只需要22us左右，在有問題的機(jī)器上竟然花掉來 2500us，上漲了100倍。我們用strace -c $PID查看一下出問題時和正常時的connect系統(tǒng)調(diào)用耗時對比：
圖1.png
<centor>圖1：正常情況下</centor>
圖2.png
<centor>圖2：出問題時</centor>
然后回想起了..*.122:6390的TIME-WAIT已經(jīng)超過了3W，會不會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多個，也就是說端口已經(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);
}
從上面源代碼可見，臨時端口選擇過程是生成一個隨機(jī)數(shù)，利用隨機(jī)數(shù)在ip_local_port_range范圍內(nèi)取值，如果取到的值在ip_local_reserved_ports范圍內(nèi) ，那就再依次取下一個值，直到不在ip_local_reserved_ports范圍內(nèi)為止。原來臨時端口竟然是隨機(jī)撞。出。來。的。。 也就是說假如就有range里配置了5W個端口可以用，已經(jīng)使用掉了49999個。那么新建立連接的時候，可能需要調(diào)用這個隨機(jī)函數(shù)5W次才能撞到這個沒用的端口身上。
所以請記得要保證你可用臨時端口的充裕，避免你的connect系統(tǒng)調(diào)用進(jìn)入SB模式。正常端口充足的時候，只需要22usec。但是一旦出現(xiàn)端口緊張，則一次系統(tǒng)調(diào)用耗時會上升到2.5ms，整整多出100倍。這個開銷比正常tcp連接的建立吃掉的cpu時間（每個30usec左右）的開銷要大的多。
解決TIME_WAIT的辦法除了放寬端口數(shù)量限制外，還可以考慮設(shè)置net.ipv4.tcp_tw_recycle和net.ipv4.tcp_tw_reuse這兩個參數(shù)，避免端口長時間保守地等待2MSL時間。
歡迎關(guān)注個人公眾號“開發(fā)內(nèi)功修煉”，打通理論與實(shí)踐的任督二脈
參考文獻(xiàn)
- 臨時端口號(EPHEMERAL PORT)的動態(tài)分配
- connect系統(tǒng)調(diào)用
