小菜成長之路，警惕淪為 API 調用俠
小菜(化名)在某互聯網公司擔任運維工程師，負責公司後台業務的運維保障工作。由於自己編程經驗不多，平時有不少工作需要開發協助。
聽說 Python 很火，能快速開發一些運維腳本，小菜也加入 Python 大軍學起來。 Python 語言確實簡單，小菜很快就上手了，覺得自己應對運維開發工作已經綽綽有餘，便不再深入研究。
背景
這天老闆給小菜派了一個數據採集任務，要實時統計服務器 TCP 連接數。需求背景是這樣的：開發同事需要知道服務的連接數以及不同狀態連接的比例，以便判斷服務狀態。
因此，小菜需要開發一個腳本，定期採集並報告 TCP 連接數，提交數據格式定為 json ：
{
"LISTEN": 4,
"ESTABLISHED": 100,
"TIME_WAIT": 10
}
作為運維工程師，小菜當然知道怎麼查看系統 TCP 連接。
Linux 系統中有兩個命令可以辦到， netstat 和 ss ：
$ netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:8388 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 192.168.56.3:22 192.168.56.1:54983 ESTABLISHED
tcp6 0 0 :::22 :::* LISTEN
$ ss -nat
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 127.0.0.1:8388 0.0.0.0:*
LISTEN 0 128 127.0.0.53%lo:53 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
ESTAB 0 0 192.168.56.3:22 192.168.56.1:54983
LISTEN 0 128 [::]:22 [::]:*
小菜還知道 ss 命令比 netstat 命令要快，但至於為什麼，小菜就不知道了。
小菜很快找到老闆，提出了自己的解決方案：寫一個 Python 程序，調用 ss 命令採集 TCP 連接信息，然後再逐條統計。
老闆告訴小菜，線上服務器很多都是最小化安裝，並不能保證每台機器上都有 ss 或者 netstat 命令。
老闆還告訴小菜，程序開發要學會 站在巨人的肩膀上 。動手寫代碼前，先調研一番，看是否有現成的解決方案。 切忌重複造輪子 ，浪費時間不說，可能代碼質量還差，效果也不好。
最後老闆給小菜指了條明路，讓他回去再看看 psutil 。 psutil 是一個 Python 第三方包，用於採集系統性能數據，包括： CPU 、內存、磁盤、網卡以及進程等等。臨走前，老闆還叮囑小菜，完成工作后花點時間研究下這個庫。
psutil 方案
小菜搜索 psutil 發現，原來有這麼順手的第三方庫，喜出望外！他立馬裝好 psutil ，準備開干：
$ pip install psutil
導入 psutil 后，一個函數調用就可以拿到系統所有連接，連接信息非常豐富：
>>> import psutil
>>> for conn in psutil.net_connections('tcp'):
... print(conn)
...
sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='192.168.56.3', port=22), raddr=addr(ip='192.168.56.1', port=54983), status='ESTABLISHED', pid=None)
sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='127.0.0.1', port=8388), raddr=(), status='LISTEN', pid=None)
sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='0.0.0.0', port=22), raddr=(), status='LISTEN', pid=None)
sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='127.0.0.53', port=53), raddr=(), status='LISTEN', pid=None)
sconn(fd=-1, family=<AddressFamily.AF_INET6: 10>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='::', port=22), raddr=(), status='LISTEN', pid=None)
小菜很滿意，感覺不用花多少時間就可搞定數據採集需求了，準時下班有望！噼里啪啦，很快小菜就寫下這段代碼：
import psutil
from collections import defaultdict
# 遍歷每個連接，按連接狀態累加
stats = defaultdict(int)
for conn in psutil.net_connections('tcp'):
stats[conn.status] += 1
# 遍歷每種狀態，輸出連接數
for status, count in stats.items():
print(status, count)
小菜接着在服務器上測試這段代碼，功能完全正常：
ESTABLISHED 1
LISTEN 4
小菜將數據採集腳本提交，並按既定節奏逐步發布到生產服務器上。開發同事很快就看到小菜採集的數據，都誇小菜能力不錯，需求完成得很及時。小菜也很高興，感覺 Python 沒白學。如果用其他語言開發，說不定現在還在加班加點呢！Life is short, use Python! 果然沒錯！
小菜愈發自信，早就把老闆的話拋到腦後了。 psutil 這個庫這麼好上手，有啥好深入研究的？
內存悲劇
突然有一天，其他同事緊急告訴小菜，他開發的採集腳本佔用很多內存， CPU 也跑到了 100% ，已經開始影響線上服務了。小菜還沉浸在成功的喜悅中，收到這個反饋如同晴天霹靂，有點举手無措。
業務同事告訴小菜，受影響的機器系統連接數非常大，質疑小菜是不是腳本存在性能問題。小菜覺得很背，腳本只是調用 psutil 並統計數據，怎麼就攤上性能故障？腳本影響線上服務，小菜壓力很大，但不知道如何是好，只能跑去找老闆尋求幫助。
老闆要小菜第一時間停止數據採集，降低影響。復盤故障時，老闆很敏銳地問小菜，是不是用容器保存所有連接了？小菜自己並沒有，但是 psutil 這麼做了：
>>> psutil.net_connections()
[sconn(fd=-1, family=<AddressFamily.AF_INET6: 10>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='::', port=22), raddr=(), status='LISTEN', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='0.0.0.0', port=22), raddr=(), status='LISTEN', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='127.0.0.53', port=53), raddr=(), status='LISTEN', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_DGRAM: 2>, laddr=addr(ip='10.0.2.15', port=68), raddr=(), status='NONE', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_DGRAM: 2>, laddr=addr(ip='127.0.0.1', port=8388), raddr=(), status='NONE', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='192.168.56.3', port=22), raddr=addr(ip='192.168.56.1', port=54983), status='ESTABLISHED', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_DGRAM: 2>, laddr=addr(ip='127.0.0.53', port=53), raddr=(), status='NONE', pid=None), sconn(fd=-1, family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, laddr=addr(ip='127.0.0.1', port=8388), raddr=(), status='LISTEN', pid=None)]
psutil 將採集到的所有 TCP 連接放在一個列表裡返回。如果服務器上有十萬個 TCP 連接，那麼列表裡將有十萬個連接對象。難怪採集腳本吃了那麼多內存！
老闆告訴小菜，可以用生成器加以解決。與列表不同，生成器逐個返回數據，因此不會佔用太多內存。Python2 中 range 和 xrange 函數的區別也是一樣的道理。
小菜從 pstuil fork 了一個分支，並將 net_connections 函數改造成 生成器 ：
def net_connections():
while True:
if done:
break
# 解析一個TCP連接
conn = xxx
yield conn
代碼上線后，採集腳本內存佔用量果然下降了！ 生成器 將統計算法的空間複雜度由原來的 O(n) 優化為 O(1) 。經過這次教訓，小菜不敢再盲目自信了，他決定抽時間好好看看 psutil 的源碼。
源碼體會
深入學習源碼后，小菜發現原來 psutil 採集 TCP 連接數的秘笈是：從 /proc/net/tcp 以及 /proc/net/tcp6 讀取連接信息。
由此，他還進一步了解到 procfs ，這是一個偽文件系統，將內核空間信息以文件方式暴露到用戶空間。 /proc/net/tcp 文件則是提供內核 TCP 連接信息：
$ cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 0100007F:20C4 00000000:0000 0A 00000000:00000000 00:00000000 00000000 65534 0 18183 1 0000000000000000 100 0 0 10 0
1: 3500007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 101 0 16624 1 0000000000000000 100 0 0 10 0
2: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 18967 1 0000000000000000 100 0 0 10 0
3: 0338A8C0:0016 0138A8C0:D6C7 01 00000000:00000000 02:00023B11 00000000 0 0 22284 4 0000000000000000 20 13 23 10 20
小菜還注意到，連接信息看起來像個自定義類對象，但其實是一個 nametuple ：
# psutil.net_connections()
sconn = namedtuple('sconn', ['fd', 'family', 'type', 'laddr', 'raddr',
'status', 'pid'])
小菜一開始並不知道作者為啥要這麼做。後來，小菜開始研究 Python 源碼，學習了 Python 類機制后他恍然大悟。
Python 自定義類的每個實例對象均需要一個 dict 來保存對象屬性，這也就是對象的 屬性空間 。
如果用自定義類來實現，每個連接都需要創建一個字典，而字典又是 散列表 實現的。如果系統存在成千上萬的連接，開銷可想而知。
小菜將學到的知識總結起來：對於 數量大 而 屬性固定 的實體，沒有必要用自定義類來實現，用 nametuple 更合適，開銷更小。由此，小菜不經由衷佩服 psutil 的作者。
CPU悲劇
後來小菜又收到業務反饋，採集腳本在高併發的服務器上， CPU 使用率很高，需要再優化一下。
小菜回憶 psutil 源碼，很快就找到了性能瓶頸處： psutil 將連接信息所有字段都解析了，而採集腳本只需要其中的 狀態 字段而已。
跟老闆商量后，小菜決定自行讀取 procfs 來實現採集腳本，只解析狀態字段，避免不必要的計算開銷。
procfs 方案
直接讀取 /proc/net/tcp ，可以得到完整的 TCP 連接信息：
>>> with open('/proc/net/tcp') as f:
... for line in f:
... print(line.rstrip())
...
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 0100007F:20C4 00000000:0000 0A 00000000:00000000 00:00000000 00000000 65534 0 18183 1 0000000000000000 100 0 0 10 0
1: 3500007F:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000 101 0 16624 1 0000000000000000 100 0 0 10 0
2: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 18967 1 0000000000000000 100 0 0 10 0
3: 0338A8C0:0016 0138A8C0:D6C7 01 00000000:00000000 02:0007169E 00000000 0 0 22284 3 0000000000000000 20 20 33 10 20
其中， IP 、端口、狀態等字段都是以十六進制編碼的。例如， st 列表示狀態，狀態碼 0A 表示 LISTEN 。很快小菜就寫下這段代碼：
from collections import defaultdict
stat_names = {
'0A': 'LISTEN',
'01': 'ESTABLISHED',
# ...
}
# 遍歷每個連接，按連接狀態累加
stats = defaultdict(int)
with open('/proc/net/tcp') as f:
# 跳過表頭行
f.readline()
for line in f:
st = line.strip().split()[3]
stats[st] += 1
for st, count in stats.items():
print(stat_names[st], count)
現在，小菜寫代碼比之前講究多了。在統計連接數時，他並不急於將狀態碼解析成名字，而是按原樣統計。等統計完成，他再一次性轉換，這樣狀態碼轉換開銷便降到最低： O(1) 而不是 O(n) 。
這次改進符合業務同事預期，但小菜決定好好做一遍性能測試，不打無準備之仗。他找業務同事要了一個連接數最大的 /proc/net/tcp 樣本，拉到本地測試。測試結果還算符合預期，採集腳本能夠扛住十萬連接採集壓力。
性能測試中，小菜發現了一個比較奇怪的問題。同樣的連接規模，把 /proc/net/tcp 拉到本地跑比直接在服務器上跑要快，而本地電腦性能肯定比不上服務器。
他百思不得其解，又去找老闆幫忙。老闆很快指出到其中的區別，將 /proc/net/tcp 拉到本地就成為普通 磁盤文件 ，而 procfs 是內核映射出來的 偽文件 ，並不是磁盤文件。
他讓小菜研究一下 Python 文件 IO 以及內核 IO 子系統在處理這兩種文件時有什麼區別，還讓小菜特別留意 IO 緩衝區大小。
IO緩衝
小菜打開一個普通的磁盤文件，發現 Python 選的默認緩衝區大小是 4K (讀緩存對象頭 152 字節)：
>>> f = open('test.py')
>>> f.buffer.__sizeof__()
4248
但是如果打開的是 procfs 文件， Python 選的緩衝區卻只有 1K ，相差了 4 倍呢！
>>> f = open('/proc/net/tcp')
>>> f.buffer.__sizeof__()
1176
因此，理論上 Python 默認讀取 procfs 發生的上下文切換次數是普通磁盤文件的 4 倍，怪不得會慢。
雖然小菜還不知道這種現象背後的原因，但是他已經知道怎麼進行優化了。隨即他決定將緩衝區設置為 1M 以上，盡量避免 IO 上下文切換，以空間換時間：
with open('/proc/net/tcp', buffering=1*1024*1024) as f:
# ...
經過這次優化，採集腳本在大部分服務器上運行良好，基本可以高枕無憂了。而小菜也意識到 編程語言 以及 操作系統 等底層基礎知識的重要性，他開始制定學習計劃補全計算機基礎知識。
netlink 方案
後來負載均衡團隊找到小菜，他們也想統計服務器上的連接信息。由於負載均衡服務器作為入口轉發流量，連接數規模特別大，達到幾十萬，將近百萬的規模。小菜決定好好進行性能測試，再視情況上線。
測試結果並不樂觀，採集腳本要跑幾十秒鐘才完成， CPU 跑到 100% 。小菜再次調高 IO 緩衝區，但效果不明顯。小菜又測試了 ss 命令，發現 ss 命令要快很多。由於之前嘗到了閱讀源碼的甜頭，小菜很想到 ss 源碼中尋找秘密。
由於項目時間較緊，老闆提醒小菜先用 strace 命令追蹤 ss 命令的系統調用，便可快速獲悉 ss 的實現方式。老闆演示了 strace 命令的用法，很快就找到了 ss 的秘密 —— Netlink ：
$ strace ss -nat
...
socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_SOCK_DIAG) = 3
...
Netlink 套接字是 Linux 提供通訊機制，可用於內核與進程間、進程與進程間通訊。 Netlink 下的 sock_diag 子系統，提供了一種從內核獲取套接字信息的新方式。
與 procfs 不同，sock_diag 採用網絡通訊的方式，內核作為服務端接收客戶端進程查詢請求，並以二進制數據包響應查詢結果，效率更高。
這就是 ss 比 netstat 更快的原因， ss 採用 Netlink 機制，而 netstat 採用 procfs 機制。
很不幸 Python 並沒有提供 Netlink API ，一般人可能又要干著急了。好在小菜先前有意識地研究了部分 Python 源碼，對 Python 的運行機制有所了解。
他知道可以用 C 寫一個 Python 擴展模塊，在 C 語言中調用原生系統調用。
編寫 Python C 擴展模塊可不簡單，對編程功底要求很高，必須全面掌握 Python 運行機制，特別是對象內存管理。
一朝不慎可能導致程序異常退出、內存泄露等棘手問題。好在小菜已經不是當年的小菜了，他經受住了考驗。
小菜的擴展模塊上線后，效果非常好，頂住了百萬級連接的採集壓力。
一個看似簡單得不能再簡單的數據採集需求，背後涉及的知識可真不少，沒有一定的水平還真搞不定。好在小菜成長很快，他最終還是徹底地解決了性能問題，找回了久違的信心。
內核模塊方案
雖然性能問題已經徹底解決，小菜還是沒有將其淡忘。
他時常想：如果可以將統計邏輯放在內核空間做，就不用在內核和進程之間傳遞大量連接信息了，效率應該是最高的！受限於當時的知識水平，小菜還沒有能力實現這個設想。
後來小菜在研究 Linux 內核時，發現可以用內核模塊來擴展內核的功能，結合 procfs 的工作原理，他找到了技術方案！他順着 /proc/net/tcp 在內核中的實現源碼，依樣畫葫蘆寫了這個內核模塊：
#include <linux/module.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
#include <net/tcp.h>
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Xiaocai");
MODULE_DESCRIPTION("TCP state statistics");
MODULE_VERSION("1.0");
// 狀態名列表
static char *state_names[] = {
NULL,
"ESTABLISHED",
"SYN_SENT",
"SYN_RECV",
"FIN_WAIT1",
"FIN_WAIT2",
"TIME_WAIT",
"CLOSE",
"CLOSE_WAIT",
"LAST_ACK",
"LISTEN",
"CLOSING",
NULL
};
static void stat_sock_list(struct hlist_nulls_head *head, spinlock_t *lock,
unsigned int state_counters[])
{
// 套接字節點指針(用於遍歷)
struct sock *sk;
struct hlist_nulls_node *node;
// 鏈表為空直接返回
if (hlist_nulls_empty(head)) {
return;
}
// 自旋鎖鎖定
spin_lock_bh(lock);
// 遍歷套接字鏈表
sk = sk_nulls_head(head);
sk_nulls_for_each_from(sk, node) {
if (sk->sk_state < TCP_MAX_STATES) {
// 自增狀態計數器
state_counters[sk->sk_state]++;
}
}
// 自旋鎖解鎖
spin_unlock_bh(lock);
}
static int tcpstat_seq_show(struct seq_file *seq, void *v)
{
// 狀態計數器
unsigned int state_counters[TCP_MAX_STATES] = { 0 };
unsigned int state;
// TCP套接字哈希槽序號
unsigned int bucket;
// 先遍歷Listen狀態
for (bucket = 0; bucket < INET_LHTABLE_SIZE; bucket++) {
struct inet_listen_hashbucket *ilb;
// 哈希槽
ilb = &tcp_hashinfo.listening_hash[bucket];
// 遍歷鏈表並統計
stat_sock_list(&ilb->head, &ilb->lock, state_counters);
}
// 遍歷其他狀態
for (bucket = 0; bucket < tcp_hashinfo.ehash_mask; bucket++) {
struct inet_ehash_bucket *ilb;
spinlock_t *lock;
// 哈希槽鏈表
ilb = &tcp_hashinfo.ehash[bucket];
// 保護鎖
lock = inet_ehash_lockp(&tcp_hashinfo, bucket);
// 遍歷鏈表並統計
stat_sock_list(&ilb->chain, lock, state_counters);
}
// 遍歷狀態輸出統計值
for (state = TCP_ESTABLISHED; state < TCP_MAX_STATES; state++) {
seq_printf(seq, "%-12s: %d\n", state_names[state], state_counters[state]);
}
return 0;
}
static int tcpstat_seq_open(struct inode *inode, struct file *file)
{
return single_open(file, tcpstat_seq_show, NULL);
}
static const struct file_operations tcpstat_file_ops = {
.owner = THIS_MODULE,
.open = tcpstat_seq_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release
};
static __init int tcpstat_init(void)
{
proc_create("tcpstat", 0, NULL, &tcpstat_file_ops);
return 0;
}
static __exit void tcpstat_exit(void)
{
remove_proc_entry("tcpstat", NULL);
}
module_init(tcpstat_init);
module_exit(tcpstat_exit);
內核模塊編譯好並加載到內核后， procfs 文件系統提供了一個新文件 /proc/tcpstat ，內容為統計結果：
$ cat /proc/tcpstat
ESTABLISHED : 5
SYN_SENT : 0
SYN_RECV : 0
FIN_WAIT1 : 0
FIN_WAIT2 : 0
TIME_WAIT : 1
CLOSE : 0
CLOSE_WAIT : 0
LAST_ACK : 0
LISTEN : 14
CLOSING : 0
當用戶程序讀取這個文件時，內核虛擬文件系統( VFS )調用小菜在內核模塊中寫的處理函數：遍歷內核 TCP 套接字完成統計並格式化統計結果。內核模塊、 VFS 以及套接字等知識超出專欄範圍，不再贅述。
小菜在服務器上試驗這個內核模塊，真的快得飛起！
經驗總結
小菜開始總結這次腳本開發工作中的經驗教訓，他列出了以下關鍵節點：
- 依靠 psutil 採集，沒有關注 psutil 實現導致性能問題；
- 用生成器代替列表返回連接信息，解決內存瓶頸；
- 直接讀取 procfs 文件系統，部分解決 CPU 性能瓶頸；
- 通過調節 IO 緩衝區大小，進一步降低 CPU 開銷；
- 用 Netlink 代替 procfs ，徹底解決性能問題；
- 實驗內核模塊思路，終極解決方案快得飛起；
這些問題節點，一個比一個深入，沒有一定功底是搞不定的。小菜從剛開始跌跌撞撞，到後來獨當一面，快速成長的關鍵在於善於在問題中總結經驗教訓：
- 程序開發完一定要做性能測試，看能夠扛住多大的壓力；
- 使用任何工具，需要準確理解其背後的原理，避免誤用；
- 對編程語言以及操作系統源碼要保持好奇心；
- 計算機基礎知識很重要，需要及時補全才能達到新高度；
- 學會問題發散，舉一反三；
更多章節
洞悉 Python 虛擬機運行機制，探索高效程序設計之道！
到底如何才能提升我的 Python 開發水平，向更高一級的崗位邁進？ 如果你有這些問題或者疑惑，請訂閱我們的專欄，閱讀更多章節：
- 內建對象
- 虛擬機
- 函數機制
- 類機制
- 生成器與協程
- 內存管理機制
附錄
更多 Python 技術文章請訪問：小菜學Python，轉至 原文 可獲得最佳閱讀體驗。
訂閱更新，獲取更多學習資料，請關注 小菜學編程 ：
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線
※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整
※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!
※教你寫出一流的銷售文案?
※超省錢租車方案