mTCP 和 DPDK 構造百萬千萬併發TCP連線
1 Linux Kernel 網路處理瓶頸.
以下連線大概描述Linux Kernel的網路處理瓶頸
簡化的Linux 網路報文處理流程如下:
NIC RX/TX queues<-->Ring Buffers<-->Driver<-->Socket<-->App
實際的Linux網路報文處理流程
其中瓶頸如下 (慮述其他方面如skbuff, netfilter framework, memory allocation, ip routing...):
-
昂貴的系統呼叫 (System calls)
-
Blocking I/O 的上下文切換 (Context switching on blocking I/O)
-
網路報文在kernel 和 user space之間的複製 (Data Copying from kernel to user space)
-
kernel 的終斷(Interrupt) 處理 包括軟硬終斷( Interrupt handling in kernel)
針對以上瓶頸,我們首先從網絡卡driver上來看, 開源軟體DPDK是怎麼解決問題的.
2 網路報文在DPDK的處理流程
NIC RX/TX queues<-->Ring Buffers<-->DPDK<-->App
更準確的說,DPDK不僅僅是網絡卡PMD (Poll Mode Driver) Driver library,DPDK還包含記憶體優化管理,thread 管理等等.
具有:
-
處理器粘合性 (Processor affinity)
-
大記憶體頁提高CPU 快取使用率, 減少主記憶體swap (Huge pages( no swap, TLB))
-
kernel提供的UIO (User space I/O), 去除Kernel和User space之間的網路報文複製 ((no copying from kernel))
-
Poll Mode Driver (PMD) 去除終斷(Interrupt)處理模式的瓶頸 (Polling (no interrupts overhead))
-
無鎖同步機制 (Lockless synchronization(avoid waiting))
-
網路報文批處理 (Batch packets handling)
-
利用CPU SSE指令特性.
-
處理器本地記憶體使用特性 CPU NUMA awareness
現在我們來看看mTCP 是怎麼來解決Linux TCP/IP, socket system call 瓶頸的
3 mTCP 設計原理
首先kernel 具有以下侷限性:
-
無TCP connection 處理器粘合性 (Lack of connection locality) - 處理網路報文終斷的CPU可能和執行應用程式的CPU不一致
-
執行程式檔案字元 (File descriptor) 共享限制可用檔案字元數. ( Shared file descriptor space)
-
單個網路報文處理 (Inefficient per-packet processing)
-
系統呼叫成本高 System call overhead
mTCP 設計特性:
-
批處理網路報文, TCP stream 以去除系統呼叫成本 (Batching in packet I/O, TCP processing, user applications ( reduce system call overhead))
-
多處理器系統上,同一連線在同一處理器上處理以提高處理器快取使用率 (Connection locality on multicore systems - handling same connection on same core, avoid cache pollution (solve connection locality))
-
mTCP 執行緒之間不分享檔案字元 ( No descriptor sharing between mTCP thread)
mTCP 網路報文處理流程:
DPDK/Netmap<-->mTCP thread<-->mTCP socket/epoll<-->mTCP App thread
我針對mTCP 及應用epwget 做細微的改進,在此基礎上演變出一些有用的壓力測試程式如syn flood 測試, SSL DOS 測試, ApacheBench SSL mTCP 移植, 等等, 下面就是mTCP應用測試列子
4 mTCP 客戶端應用測試實列
硬體配置
Hardware SPEC:
mTCP+DPDK: Dell Poweredge R710 72G MEM, 16 core, Intel NIC 82599
BIGIP DUT: Victoria B2250 Intel(R) Xeon(R) CPU E5-2658 v2 @ 2.40GHz 20 cores 64G MEM
4a 千萬併發HTTP 連線測試
mTCP 客戶端應用
#epwget 10.3.3.249/ 160000000 -N 16 –c 10000000
[CPU 0] dpdk0 flows: 625000, RX: 96382(pps) (err: 0), 0.10(Gbps), TX: 413888(pps), 0.64(Gbps)
[CPU 1] dpdk0 flows: 625000, RX: 101025(pps) (err: 0), 0.10(Gbps), TX: 398592(pps), 0.61(Gbps)
.................................................CUT.....................
[CPU15] dpdk0 flows: 625000, RX: 103412(pps) (err: 0), 0.11(Gbps), TX: 391296(pps), 0.60(Gbps)
[ ALL ] dpdk0 flows: 10010366, RX: 1634404(pps) (err: 0), 1.69(Gbps), TX: 6489408(pps), 9.96(Gbps)
F5 BIGIP CPU
top - 15:25:26 up 23:57, 1 user, load average: 0.16, 0.33, 0.43
Tasks: 778 total, 17 running, 761 sleeping, 0 stopped, 0 zombie
Cpu(s): 45.1%us, 30.6%sy, 0.0%ni, 24.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 66080376k total, 62855960k used, 3224416k free, 136316k buffers
Swap: 5242872k total, 0k used, 5242872k free, 1182216k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17283 root 1 -19 57.9g 145m 123m R 94.1 0.2 1322:36 tmm.0 -T 10 --tmid BIGIP CPU 使用情況
.......................................CUT..................
17285 root 1 -19 57.9g 145m 123m R 92.1 0.2 1322:37 tmm.0 -T 10 --tmid
31507 root RT 0 0 0 0 R 32.0 0.0 0:00.97 [enforcer/19]
................................CUT.....................
31515 root RT 0 0 0 0 S 16.8 0.0 0:00.51 [enforcer/1]
F5 BIGIP 記憶體使用狀態
[[email protected]:/S1-green-P:Active:Standalone] config # tail -f /var/log/ltm
Nov 4 15:25:29 slot1/bigip1 warning tmm7[17043]: 011e0003:4: Aggressive mode sweeper: /Common/default-eviction-policy (70000000002d6) (global memory) 9864 Connections killed
Nov 4 15:25:29 slot1/bigip1 warning tmm7[17043]: 011e0002:4:sweeper_policy_bind_deactivation_update: Aggressive mode /Common/default-eviction-policy deactivated (70000000002d6) (global memory). (12793204/15051776 pages)
Every 1.0s: tmsh show ltm virtual vs_http_10g Wed Nov 4 15:27:15 2015
CMP : enabled
CMP Mode : all-cpus
Destination : 10.3.3.249:80
PVA Acceleration : none
Traffic ClientSide Ephemeral General
Packets In 287.6M 0 -
Packets Out 150.2M 0 -
Current Connections 6.1M 0 - 當前併發TCP 連線
Maximum Connections 6.7M 0 -
Total Connections 39.8M 0 -
mTCP 函式CPU使用狀況, %70 CPU時間為mTCP所有 perf top output ~70% cycles in Userspace
Samples: 1M of event 'cycles', Event count (approx.): 441906428558
8.25% epwget [.] SendTCPPacket
7.93% [kernel] [k] _raw_spin_lock
7.16% epwget [.] GetRSSCPUCore
7.15% epwget [.] IPOutput
4.26% libc-2.19.so [.] memset
4.10% epwget [.] ixgbe_xmit_pkts
3.62% [kernel] [k] clear_page_c
3.26% epwget [.] WriteTCPControlList
3.24% [vdso] [.] 0x0000000000000cf9
2.95% epwget [.] AddtoControlList
2.70% epwget [.] MTCPRunThread
2.66% epwget [.] HandleRTO
2.51% epwget [.] CheckRtmTimeout
2.10% libpthread-2.19.so [.] pthread_mutex_unlock
1.83% epwget [.] dpdk_send_pkts
1.68% epwget [.] HTInsert
1.65% epwget [.] CreateTCPStream
1.42% epwget [.] MPAllocateChunk
1.29% epwget [.] TCPCalcChecksum
1.24% epwget [.] dpdk_recv_pkts
1.20% epwget [.] mtcp_getsockopt
1.12% epwget [.] rx_recv_pkts
4b mTCP SSL DOS 客戶應用端測試實列
mTCP 客戶端應用
#brute-shake 10.3.3.249/ 160000000 -N 16 –c 3200
F5 BIGIP CPU使用情況
top - 09:10:21 up 22:58, 1 user, load average: 10.45, 4.43, 1.67
Tasks: 782 total, 19 running, 763 sleeping, 0 stopped, 0 zombie
Cpu(s): 50.6%us, 40.1%sy, 0.1%ni, 9.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 66080376k total, 62923192k used, 3157184k free, 138624k buffers
Swap: 5242872k total, 0k used, 5242872k free, 1259132k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21480 root 1 -19 57.9g 145m 123m R 100.0 0.2 81:24.41 tmm
............................CUT...................
21511 root 1 -19 57.9g 145m 123m R 100.0 0.2 47:06.64 tmm
1670 root RT 0 0 0 0 R 80.2 0.0 2:07.03 enforcer/15
...............................................CUT........................
1672 root RT 0 0 0 0 R 79.9 0.0 2:07.02 enforcer/5
4c mTCP Apachebench SSL port 客戶應用端測試實列
#ab -n 16000 -N 16 -c 8000 -L 64 https://10.3.3.249/
---------------------------------------------------------------------------------
Loading mtcp configuration from : /etc/mtcp/config/mtcp.conf
Loading interface setting
EAL: Detected lcore 0 as core 0 on socket 0
................................................. Checking link statusdone
Port 0 Link Up - speed 10000 Mbps - full-duplex
Benchmarking 10.3.3.249 (be patient)
CPU6 connecting to port 443
.............................CUT.............
CPU0 connecting to port 443
.......................................
[ ALL ] dpdk0 flows: 5016, RX: 9651(pps) (err: 0), 0.04(Gbps), TX: 14784(pps), 0.02(Gbps)
4d mTCP HTTP 客戶應用端使用隨機source MAC地址實列
相關推薦
mTCP 和 DPDK 構造百萬千萬併發TCP連線
在F5 Networks Seattle 總部從事大型企業網路應用交付使用的維護支援經歷中, 經常碰到客戶應用達到百萬至千萬級TCP連線時BIGIP可能會遇到的各種瓶勁,如記憶體分配使用狀態,CPU 負荷, TCP 協議棧效能. TCP software syncookie
【 Linux 】單臺伺服器上併發TCP連線數(轉)
單臺伺服器上併發TCP連線數 問題:一臺伺服器到底能夠支援多少TCP併發連線呢?1. 檔案描述符限制: 對於伺服器來說,每一個TCP連線都要佔用一個檔案描述符,一旦檔案描述符使用完,新的連線到來返回給我們的錯誤是"Socket/File:
socket跟TCP/IP 的關係,單臺伺服器上的併發TCP連線數可以有多少
常識一:檔案控制代碼限制 在linux下編寫網路伺服器程式的朋友肯定都知道每一個tcp連線都要佔一個檔案描述符,一旦這個檔案描述符使用完了,新的連線到來返回給我們的錯誤是“Socket/File:Can'topen so many files”。 這時你需要明白作業系統對可以開啟的最大檔案數
高效能網路程式設計(一):單臺伺服器併發TCP連線數到底可以有多少
前言 曾幾何時我們還在尋求網路程式設計中C10K問題(有關C10K問題請見文章《The C10K problem(英文線上閱讀、英文PDF版下載、中文譯文)》)的解決方案,但是現在從硬體和作業系統支援來看單臺伺服器支援上萬併發連線已經沒有多少挑戰性了。 我們先假設單臺伺服器最多隻能支援萬級併發連線,其實
高效能網路程式設計(一):單臺伺服器併發TCP連線數到底可以有多少?
引言 曾幾何時我們還在尋求網路程式設計中C10K問題(有關C10K問題請見文章《The C10K problem(英文線上閱讀、英文PDF版下載、中文譯文)》)的解決方案,但是現在從硬體和作業系統支援來看單臺伺服器支援上萬併發連線已經沒有多少挑戰性了。我們先假設單臺伺服
高併發TCP連線數目問題
linux可通過五元組唯一確定一個連結:源IP,源埠,目的IP,目的埠,傳輸層協議。而一個埠不允許被兩個及以上程序佔用(一個程序可同時佔用多個埠),據此是否可以推測一臺linux伺服器最多可以同時處理2^16(65536,或65K)個連結即併發請求呢? 一臺伺服器到底能夠支援多少TCP併發連線呢? 1.
單臺伺服器上的併發TCP連線數可以有多少
曾幾何時我們還在尋求網路程式設計中C10K問題的解決方案,但是現在從硬體和作業系統支援來看單臺伺服器支援上萬併發連線已經沒有多少挑戰性了。我們先假設單臺伺服器最多隻能支援萬級併發連線,其實對絕大多數應用來說已經遠遠足夠了,但是對於一些擁有很大使用者基數的網際網路公司,往往
CentOS6.8檢視nginx併發連線數和TCP連線狀態命令
荊軻刺秦王 1.檢視nginx執行程序數 [[email protected] ~]# ps -ef|grep nginx |wc -l 6 檢視httpd程序數 [[email
Centos6.5檢視nginx併發連線數和TCP連線狀態命令
1、檢視nginx執行程序數 [[email protected] logs]# ps -ef | grep nginx | wc -l 10 2、檢視Web伺服器程序連線數 [[email protected] logs]# netstat -antp
基於DPDK,jupiter 百萬qps併發負載均衡,替代lvs
一、簡介 1、背景 基於 OS 核心的資料傳輸有什麼弊端 UNIX 的設計初衷其實為電話網路的控制系統而設計的,而不是一般的伺服器作業系統,所以,它僅僅是一個數據負責資料傳送的系統,沒有所謂的控制層面和資料層面的說法,不適合處理大規模的網路資料包。最後
orcle 如何快速插入百萬千萬條數據
select evel sel inf comm nec values 如何快速 creat 有時候做實驗測試數據用到大量數據時可以用以下方法插入: 方法一:使用xmltable create table bqh8 as select rownum as id from
C++傳參構造的優化和討論構造拷貝構造N中呼叫情況
C++對傳參和傳返回值時建構函式的優化處理 1.c++形式引數型別和返回值為引用時,會把實參或者返回值引用自動賦給形式引數(返回值)。 2.c++返回值賦值和返回值使用一般會進行編譯器的優化。 3.c++函式引數(或者返回值)賦值時,如果其型別是類並且對應
HIBERNATE:disjunction和conjunction構造複雜的查詢條件.
工作中小結:(1) 查詢某個批次的資料,也還可以輸入州/縣/醫療機構(這三個是或者的關係);//disjunction或者 關係:【 批次的資料 && (州 || 縣 || &nb
Hibernate 樂觀鎖和悲觀鎖處理事物併發問題
一、5類事物併發問題 二、事物的隔離級別 三、處理第一類丟失更新和第二類丟失更新--使用鎖機制 資料庫的鎖機制: 在MYSQL中 ,為了避免第二類丟失更新出現,提供了悲觀鎖的機制; SELECT XXX FROM XXX FOR UPDATE;
新浪微博技術分享:微博實時直播答題的百萬高併發架構實踐
本文由“聲網Agora”的RTC開發者社群整理。 1、概述 本文將分享新浪微博系統開發工程師陳浩在 RTC 2018 實時網際網路大會上的演講。他分享了新浪微博直播互動答題架構設計的實戰經驗。其背後的百萬高併發實時架構,值得借鑑並用於未來更多場景中。本文正文是對演講內容的整理,請繼
TCP三次握手和四次揮手,及TCP協議埠狀態說明:CLOSE-WAIT、TIME-WAIT 、LISTENING、SYN_SENT、ESTABLISHED、LAST-ACK ...
TCP三次握手和四次揮手狀態圖: 三次握手: 第一次 第一次握手:建立連線時,客戶端傳送SYN包(syn=j)到伺服器,並進入SYN_SENT狀態,等待伺服器確認;SYN:同步序列編號(Synchronize Sequence Numbers)。 第二次 第二次握手:伺服器收到syn包
TCP連線和關閉的過程
轉載的連結處:TCP連線和關閉 建立連線:三次握手 在 TCP/IP 協議中,TCP 協議提供可靠的連線服務,採用三次握手建立一個連線,如圖1所示。 圖1 TCP三次握手建立連線的過程 客戶端 A 傳送 SYN 包(SYN=j)到伺服器 B,並進入SYN_SEND 狀態
Windows網路程式設計(三):建立TCP連線和收發訊息
先看服務端: // ConsoleApplication3.cpp : 定義控制檯應用程式的入口點。 // #include "stdafx.h" #define _WINSOCK_DEPRECATED_NO_WARNINGS //這個宣告要在stdafx.h的後面,但要
JAVA初級(六)物件和類(1)基礎介紹和使用,構造方法介紹
我是導航 1,物件和類基本概念 2,JAVA中物件和類的基礎使用 3,類的組成 1,構造方法 成員變數,方法下回在介紹. 1,物件和類基本概念 物件:物件是類的一個例項(物件不是找個女朋友),有狀態和行為
TCP連線的建立和關閉
TCP通過三次握手建立連線,通過四次揮手揮手關閉連線 1、三次握手 第一個TCP報文段包含SYN標誌,因此它是一個同步報文段,即ernest -lapyop(客戶端)向Kongmin