前面我們討論系統(tǒng)調(diào)用的時(shí)候結(jié)論是耗時(shí)200ns-15us不等艰管。不過(guò)我今天說(shuō)的我的這個(gè)遭遇可能會(huì)讓你進(jìn)一步認(rèn)識(shí)系統(tǒng)調(diào)用的真正開(kāi)銷。在本節(jié)里你會(huì)看到一個(gè)耗時(shí)2.5ms的connect系統(tǒng)調(diào)用，注意是毫秒,相當(dāng)于2500us赵抢！
問(wèn)題描述
當(dāng)時(shí)是我的一個(gè)線上云控接口瘾晃，是nginx+lua寫(xiě)的悄晃。正常情況下训唱，單虛機(jī)8核8G可以抗每秒2000左右的QPS褥蚯，負(fù)載還比較健康。但是該服務(wù)近期開(kāi)始出現(xiàn)一些500狀態(tài)的請(qǐng)求了况增，監(jiān)控時(shí)不時(shí)會(huì)出現(xiàn)報(bào)警。通過(guò)sar -u查看峰值時(shí)cpu余量只剩下了20-30%训挡。
第一步澳骤、迅速鎖定嫌疑人
top命令查看cpu使用，通過(guò)top命令發(fā)現(xiàn)峰值的時(shí)候cpu確實(shí)消耗的比較多澜薄，idle只有20-30%左右为肮。在使用的cpu里，軟中斷的占比也比較高肤京，1/3左右颊艳。
再通過(guò)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訪問(wèn)祖很，只留了必要的。
結(jié)果：峰值的cpu余量從確實(shí)多出來(lái)一些了漾脂。報(bào)警頻率確實(shí)下來(lái)了假颇，但是還是偶爾會(huì)有零星的報(bào)警」歉澹可見(jiàn)該嫌疑人并非主犯拆融。。
第二步啊终、干掉一大片镜豹，真兇在其中
接著查看網(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)超過(guò)了3W。所以端口有限例衍。原來(lái)呀昔期，上一步執(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ī)器如果作為T(mén)CP的客戶端，有如下限制
- ESTABLISH狀態(tài)的連接只能有ip_local_port_range范圍內(nèi)的個(gè)數(shù)奥吩。
- 只有針對(duì)特定ip哼蛆，特定port的TIME-WAIT過(guò)多，超過(guò)或接近ip_local_port_range霞赫，再新建立連接可能會(huì)出現(xiàn)無(wú)端口可用的情況腮介。（ 總的TIME-WAIT過(guò)多并不一定有問(wèn)題 ）
沒(méi)想到一個(gè)簡(jiǎn)單砍掉一個(gè)對(duì)redis server的tcp連接，能把cpu優(yōu)化到這么多端衰。大大出乎意料叠洗，而且也想不明白甘改。 根據(jù)我之前的性能測(cè)試經(jīng)驗(yàn)，每個(gè)tcp連接的建立大約只需要消耗36usec的cpu時(shí)間灭抑。我們來(lái)估算一下：
當(dāng)時(shí)server的qps大約在2000左右十艾，假設(shè)是均勻分布的，則8個(gè)核每個(gè)核每秒只需要處理250個(gè)請(qǐng)求名挥。也就是說(shuō)每秒一條tcp連接需要消耗的cpu時(shí)間為：250*36usec = 9ms.
也就是說(shuō)疟羹，正常來(lái)講砍掉這些握手開(kāi)銷只能節(jié)約1%左右的cpu，不至于有這么大的提升禀倔。（即使我上面的估算只考慮了建立連接榄融，沒(méi)有統(tǒng)計(jì)釋放連接的cpu開(kāi)銷，但是連接釋放cpu開(kāi)銷也和建立連接差不多救湖。）
總之愧杯，這一步確實(shí)解決了問(wèn)題，但是代價(jià)是犧牲了一個(gè)業(yè)務(wù)邏輯鞋既。
最終力九、審出真兇，真相大白于天下
我在某一臺(tái)機(jī)器上把老的有問(wèn)題的代碼回滾了回來(lái)邑闺，恢復(fù)問(wèn)題現(xiàn)場(chǎng)跌前。然后只修改一下ip_local_port_range。 然后請(qǐng)出了strace這個(gè)命令陡舅。
通過(guò)strace -c 統(tǒng)計(jì)到對(duì)于所有系統(tǒng)調(diào)用的開(kāi)銷匯總抵乓。 結(jié)果我們發(fā)現(xiàn)了connect系統(tǒng)調(diào)用這個(gè)二貨，在正常的機(jī)器上只需要22us左右靶衍，在有問(wèn)題的機(jī)器上竟然花掉來(lái) 2500us灾炭，上漲了100倍。我們用strace -c $PID查看一下出問(wèn)題時(shí)和正常時(shí)的connect系統(tǒng)調(diào)用耗時(shí)對(duì)比：
<centor>圖1：正常情況下</centor>
<centor>圖2：出問(wèn)題時(shí)</centor>
然后回想起了..*.122:6390的TIME-WAIT已經(jīng)超過(guò)了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ī)器上的端口范圍只開(kāi)了3W多個(gè)，也就是說(shuō)端口已經(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使用率非常健康。
問(wèn)題的根本原因是建立TCP連接使用的端口數(shù)量上（ip_local_port_range）不充裕煤杀，導(dǎo)致connect系統(tǒng)調(diào)用開(kāi)銷上漲了將近100倍眷蜈！
后來(lái)我們的一位開(kāi)發(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);
}
從上面源代碼可見(jiàn)，臨時(shí)端口選擇過(guò)程是生成一個(gè)隨機(jī)數(shù)沈自，利用隨機(jī)數(shù)在ip_local_port_range范圍內(nèi)取值，如果取到的值在ip_local_reserved_ports范圍內(nèi) 辜妓，那就再依次取下一個(gè)值枯途，直到不在ip_local_reserved_ports范圍內(nèi)為止忌怎。原來(lái)臨時(shí)端口竟然是隨機(jī)撞。出酪夷。來(lái)榴啸。的。晚岭。 也就是說(shuō)假如就有range里配置了5W個(gè)端口可以用鸥印，已經(jīng)使用掉了49999個(gè)。那么新建立連接的時(shí)候坦报，可能需要調(diào)用這個(gè)隨機(jī)函數(shù)5W次才能撞到這個(gè)沒(méi)用的端口身上库说。
所以請(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è)開(kāi)銷比正常tcp連接的建立吃掉的cpu時(shí)間（每個(gè)30usec左右）的開(kāi)銷要大的多嘲叔。
解決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)“開(kāi)發(fā)內(nèi)功修煉”锰什，打通理論與實(shí)踐的任督二脈
