版權
作者:nxlhero
來源:
https://blog.51cto.com/nxlhero/2515849文章内容結構
第一部分介紹生産上出現Dubbo服務擁堵的情況,以及Dubbo官方對于單個長連接配接的使用建議。
第二部分介紹Dubbo在特定配置下的通信過程,輔以代碼。
第三部分介紹整個調用過程中與性能相關的一些參數。
第四部分通過調整連接配接數和TCP緩沖區觀察Dubbo的性能。
一、背景
生産擁堵回顧
近期在一次生産釋出過程中,因為突發的流量,出現了擁堵。系統的部署圖如下,用戶端通過Http協定通路到Dubbo的消費者,消費者通過Dubbo協定通路服務提供者。這是單個機房,8個消費者3個提供者,共兩個機房對外服務。
在釋出的過程中,摘掉一個機房,讓另一個機房對外服務,然後摘掉的機房釋出新版本,然後再互換,最終兩個機房都以新版本對外服務。問題就出現單機房對外服務的時候,這時候單機房還是老版本應用。以前不知道晚上會有一個高峰,結果當晚的高峰和早上的高峰差不多了,單機房扛不住這麼大的流量,出現了擁堵。這些流量的特點是并發比較高,個别交易傳回封包較大,因為是一個産品清單頁,點選後會發送多個交易到背景。
在問題發生時,因為不清楚狀态,先切到另外一個機房,結果也擁堵了,最後整體回退,折騰了一段時間沒有問題了。當時有一些現象:
(1)提供者的CPU記憶體等都不高,第一個機房的最高CPU 66%(8核虛拟機),第二個機房的最高CPU 40%(16核虛拟機)。消費者的最高CPU隻有30%多(兩個消費者結點位于同一台虛拟機上)
(2)在擁堵的時候,服務提供者的Dubbo業務線程池(下面會詳細介紹這個線程池)并沒滿,最多到了300,最大值是500。但是把這個機房摘下後,也就是沒有外部的流量了,線程池反而滿了,而且好幾分鐘才把堆積的請求處理完。
(3)通過監控工具統計的每秒進入Dubbo業務線程池的請求數,在擁堵時,時而是0,時而特别大,在日間正常的時候,這個值不存在為0的時候。
事故原因猜測
當時其他名額沒有檢測到異常,也沒有打Dump,我們通過分析這些現象以及我們的Dubbo配置,猜測是在網絡上發生了擁堵,而影響擁堵的關鍵參數就是Dubbo協定的連接配接數,我們預設使用了單個連接配接,但是消費者數量較少,沒能充分把網絡資源利用起來。
預設的情況下,每個Dubbo消費者與Dubbo提供者建立一個長連接配接,Dubbo官方對此的建議是:
Dubbo 預設協定采用單一長連接配接和 NIO 異步通訊,适合于小資料量大并發的服務調用,以及服務消費者機器數遠大于服務提供者機器數的情況。
反之,Dubbo 預設協定不适合傳送大資料量的服務,比如傳檔案,傳視訊等,除非請求量很低。
(http://dubbo.apache.org/zh-cn/docs/user/references/protocol/dubbo.html)
以下也是Dubbo官方提供的一些常見問題回答:
為什麼要消費者比提供者個數多?
因 dubbo 協定采用單一長連接配接,假設網絡為千兆網卡,根據測試經驗資料每條連接配接最多隻能壓滿 7MByte(不同的環境可能不一樣,供參考),理論上 1 個服務提供者需要 20 個服務消費者才能壓滿網卡。
為什麼不能傳大包?
因 dubbo 協定采用單一長連接配接,如果每次請求的資料包大小為 500KByte,假設網絡為千兆網卡,每條連接配接最大 7MByte(不同的環境可能不一樣,供參考),單個服務提供者的 TPS(每秒處理事務數)最大為:128MByte / 500KByte = 262。單個消費者調用單個服務提供者的 TPS(每秒處理事務數)最大為:7MByte / 500KByte = 14。如果能接受,可以考慮使用,否則網絡将成為瓶頸。
為什麼采用異步單一長連接配接?
因為服務的現狀大都是服務提供者少,通常隻有幾台機器,而服務的消費者多,可能整個網站都在通路該服務,比如 Morgan 的提供者隻有 6 台提供者,卻有上百台消費者,每天有 1.5 億次調用,如果采用正常的 hessian 服務,服務提供者很容易就被壓跨,通過單一連接配接,保證單一消費者不會壓死提供者,長連接配接,減少連接配接握手驗證等,并使用異步 IO,複用線程池,防止 C10K 問題。
因為我們的消費者數量和提供者數量都不多,是以很可能是連接配接數不夠,導緻網絡傳輸出現了瓶頸。以下我們通過詳細分析Dubbo協定和一些實驗來驗證我們的猜測。
二、Dubbo通信流程詳解
我們用的Dubbo版本比較老,是2.5.x的,它使用的netty版本是3.2.5,最新版的Dubbo線上程模型上有一些修改,我們以下的分析是以2.5.10為例。
以圖和部分代碼說明Dubbo協定的調用過程,代碼隻寫了一些關鍵部分,使用的是netty3,dubbo線程池無隊列,同步調用,以下代碼包含了Dubbo和Netty的代碼。
整個Dubbo一次調用過程如下:
1.請求入隊
我們通過Dubbo調用一個rpc服務,調用線程其實是把這個請求封裝後放入了一個隊列裡。這個隊列是netty的一個隊列,這個隊列的定義如下,是一個Linked隊列,不限長度。
class NioWorker implements Runnable {
...
private final Queue<Runnable> writeTaskQueue = new LinkedTransferQueue<Runnable>();
...
}
主線程經過一系列調用,最終通過NioClientSocketPipelineSink類裡的方法把請求放入這個隊列,放入隊列的請求,包含了一個請求ID,這個ID很重要。
2.調用線程等待
入隊後,netty會傳回給調用線程一個Future,然後調用線程等待在Future上。這個Future是Dubbo定義的,名字叫DefaultFuture,主調用線程調用DefaultFuture.get(timeout),等待通知,是以我們看與Dubbo相關的ThreadDump,經常會看到線程停在這,這就是在等背景傳回。
public class DubboInvoker<T> extends AbstractInvoker<T> {
...
@Override
protected Result doInvoke(final Invocation invocation) throws Throwable {
...
return (Result) currentClient.request(inv, timeout).get(); //currentClient.request(inv, timeout)傳回了一個DefaultFuture
}
...
}
我們可以看一下這個DefaultFuture的實作,
public class DefaultFuture implements ResponseFuture {
private static final Map<Long, Channel> CHANNELS = new ConcurrentHashMap<Long, Channel>();
private static final Map<Long, DefaultFuture> FUTURES = new ConcurrentHashMap<Long, DefaultFuture>();
// invoke id.
private final long id; //Dubbo請求的id,每個消費者都是一個從0開始的long類型
private final Channel channel;
private final Request request;
private final int timeout;
private final Lock lock = new ReentrantLock();
private final Condition done = lock.newCondition();
private final long start = System.currentTimeMillis();
private volatile long sent;
private volatile Response response;
private volatile ResponseCallback callback;
public DefaultFuture(Channel channel, Request request, int timeout) {
this.channel = channel;
this.request = request;
this.id = request.getId();
this.timeout = timeout > 0 ? timeout : channel.getUrl().getPositiveParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT);
// put into waiting map.
FUTURES.put(id, this); //等待時以id為key把Future放入全局的Future Map中,這樣回複資料回來了可以根據id找到對應的Future通知主線程
CHANNELS.put(id, channel);
}
3.IO線程讀取隊列裡的資料
這個工作是由netty的IO線程池完成的,也就是NioWorker,對應的類叫NioWorker。它會死循環的執行select,在select中,會一次性把隊列中的寫請求處理完,select的邏輯如下:
public void run() {
for (;;) {
....
SelectorUtil.select(selector);
proce***egisterTaskQueue();
processWriteTaskQueue(); //先處理隊列裡的寫請求
processSelectedKeys(selector.selectedKeys()); //再處理select事件,讀寫都可能有
....
}
}
private void processWriteTaskQueue() throws IOException {
for (;;) {
final Runnable task = writeTaskQueue.poll();//這個隊列就是調用線程把請求放進去的隊列
if (task == null) {
break;
}
task.run(); //寫資料
cleanUpCancelledKeys();
}
}
4.IO線程把資料寫到Socket緩沖區
這一步很重要,跟我們遇到的性能問題相關,還是NioWorker,也就是上一步的task.run(),它的實作如下:
void writeFromTaskLoop(final NioSocketChannel ch) {
if (!ch.writeSuspended) { //這個地方很重要,如果writeSuspended了,那麼就直接跳過這次寫
write0(ch);
}
}
private void write0(NioSocketChannel channel) {
......
final int writeSpinCount = channel.getConfig().getWriteSpinCount(); //netty可配置的一個參數,預設是16
synchronized (channel.writeLock) {
channel.inWriteNowLoop = true;
for (;;) {
for (int i = writeSpinCount; i > 0; i --) { //每次最多嘗試16次
localWrittenBytes = buf.transferTo(ch);
if (localWrittenBytes != 0) {
writtenBytes += localWrittenBytes;
break;
}
if (buf.finished()) {
break;
}
}
if (buf.finished()) {
// Successful write - proceed to the next message.
buf.release();
channel.currentWriteEvent = null;
channel.currentWriteBuffer = null;
evt = null;
buf = null;
future.setSuccess();
} else {
// Not written fully - perhaps the kernel buffer is full.
//重點在這,如果寫16次還沒寫完,可能是核心緩沖區滿了,writeSuspended被設定為true
addOpWrite = true;
channel.writeSuspended = true;
......
}
......
if (open) {
if (addOpWrite) {
setOpWrite(channel);
} else if (removeOpWrite) {
clearOpWrite(channel);
}
}
......
}
fireWriteComplete(channel, writtenBytes);
}
正常情況下,隊列中的寫請求要通過processWriteTaskQueue處理掉,但是這些寫請求也同時注冊到了selector上,如果processWriteTaskQueue寫成功,就會删掉selector上的寫請求。如果Socket的寫緩沖區滿了,對于NIO,會立刻傳回,對于BIO,會一直等待。Netty使用的是NIO,它嘗試16次後,還是不能寫成功,它就把writeSuspended設定為true,這樣接下來的所有寫請求都會被跳過。那什麼時候會再寫呢?這時候就得靠selector了,它如果發現socket可寫,就把這些資料寫進去。
下面是processSelectedKeys裡寫的過程,因為它是發現socket可寫才會寫,是以直接把writeSuspended設為false。
void writeFromSelectorLoop(final SelectionKey k) {
NioSocketChannel ch = (NioSocketChannel) k.attachment();
ch.writeSuspended = false;
write0(ch);
}
5.資料從消費者的socket發送緩沖區傳輸到提供者的接收緩沖區
這個是作業系統和網卡實作的,應用層的write寫成功了,并不代表對面能收到,當然tcp會通過重傳能機制盡量保證對端收到。
6.服務端IO線程從緩沖區讀取請求資料
這個是服務端的NIO線程實作的,在processSelectedKeys中。
public void run() {
for (;;) {
....
SelectorUtil.select(selector);
proce***egisterTaskQueue();
processWriteTaskQueue();
processSelectedKeys(selector.selectedKeys()); //再處理select事件,讀寫都可能有
....
}
}
private void processSelectedKeys(Set<SelectionKey> selectedKeys) throws IOException {
for (Iterator<SelectionKey> i = selectedKeys.iterator(); i.hasNext();) {
SelectionKey k = i.next();
i.remove();
try {
int readyOps = k.readyOps();
if ((readyOps & SelectionKey.OP_READ) != 0 || readyOps == 0) {
if (!read(k)) {
// Connection already closed - no need to handle write.
continue;
}
}
if ((readyOps & SelectionKey.OP_WRITE) != 0) {
writeFromSelectorLoop(k);
}
} catch (CancelledKeyException e) {
close(k);
}
if (cleanUpCancelledKeys()) {
break; // break the loop to avoid ConcurrentModificationException
}
}
}
private boolean read(SelectionKey k) {
......
// Fire the event.
fireMessageReceived(channel, buffer); //讀取完後,最終會調用這個函數,發送一個收到資訊的事件
......
}
7.IO線程把請求交給Dubbo線程池
按配置不同,走的Handler不同,配置dispatch為all,走的handler如下。下面IO線程直接交給一個ExecutorService來處理這個請求,出現了熟悉的報錯“Threadpool is exhausted",業務線程池滿時,如果沒有隊列,就會報這個錯。
public class AllChannelHandler extends WrappedChannelHandler {
......
public void received(Channel channel, Object message) throws RemotingException {
ExecutorService cexecutor = getExecutorService();
try {
cexecutor.execute(new ChannelEventRunnable(channel, handler, ChannelState.RECEIVED, message));
} catch (Throwable t) {
//TODO A temporary solution to the problem that the exception information can not be sent to the opposite end after the thread pool is full. Need a refactoring
//fix The thread pool is full, refuses to call, does not return, and causes the consumer to wait for time out
if(message instanceof Request && t instanceof RejectedExecutionException){
Request request = (Request)message;
if(request.isTwoWay()){
String msg = "Server side(" + url.getIp() + "," + url.getPort() + ") threadpool is exhausted ,detail msg:" + t.getMessage();
Response response = new Response(request.getId(), request.getVersion());
response.setStatus(Response.SERVER_THREADPOOL_EXHAUSTED_ERROR);
response.setErrorMessage(msg);
channel.send(response);
return;
}
}
throw new ExecutionException(message, channel, getClass() + " error when process received event .", t);
}
}
......
}
8.服務端Dubbo線程池處理完請求後,把傳回封包放入隊列
線程池會調起下面的函數
public class HeaderExchangeHandler implements ChannelHandlerDelegate {
......
Response handleRequest(ExchangeChannel channel, Request req) throws RemotingException {
Response res = new Response(req.getId(), req.getVersion());
......
// find handler by message class.
Object msg = req.getData();
try {
// handle data.
Object result = handler.reply(channel, msg); //真正的業務邏輯類
res.setStatus(Response.OK);
res.setResult(result);
} catch (Throwable e) {
res.setStatus(Response.SERVICE_ERROR);
res.setErrorMessage(StringUtils.toString(e));
}
return res;
}
public void received(Channel channel, Object message) throws RemotingException {
......
if (message instanceof Request) {
// handle request.
Request request = (Request) message;
if (request.isTwoWay()) {
Response response = handleRequest(exchangeChannel, request); //處理業務邏輯,得到一個Response
channel.send(response); //回寫response
}
}
......
}
channel.send(response)最終調用了NioServerSocketPipelineSink裡的方法把傳回封包放入隊列。
9.服務端IO線程從隊列中取出資料
與流程3一樣
10.服務端IO線程把回複資料寫入Socket發送緩沖區
IO線程寫資料的時候,寫入到TCP緩沖區就算成功了。但是如果緩沖區滿了,會寫不進去。對于阻塞和非阻塞IO,傳回結果不一樣,阻塞IO會一直等,而非阻塞IO會立刻失敗,讓調用者選擇政策。
Netty的政策是嘗試最多寫16次,如果不成功,則暫時停掉IO線程的寫操作,等待連接配接可寫時再寫,writeSpinCount預設是16,可以通過參數調整。
for (int i = writeSpinCount; i > 0; i --) {
localWrittenBytes = buf.transferTo(ch);
if (localWrittenBytes != 0) {
writtenBytes += localWrittenBytes;
break;
}
if (buf.finished()) {
break;
}
}
if (buf.finished()) {
// Successful write - proceed to the next message.
buf.release();
channel.currentWriteEvent = null;
channel.currentWriteBuffer = null;
evt = null;
buf = null;
future.setSuccess();
} else {
// Not written fully - perhaps the kernel buffer is full.
addOpWrite = true;
channel.writeSuspended = true;
11.資料傳輸
資料在網絡上傳輸主要取決于帶寬和網絡環境。
12.用戶端IO線程把資料從緩沖區讀出
這個過程跟流程6是一樣的
13.IO線程把資料交給Dubbo業務線程池
這一步與流程7是一樣的,這個線程池名字為DubboClientHandler。
14.業務線程池根據消息ID通知主線程
先通過HeaderExchangeHandler的received函數得知是Response,然後調用handleResponse,
public class HeaderExchangeHandler implements ChannelHandlerDelegate {
static void handleResponse(Channel channel, Response response) throws RemotingException {
if (response != null && !response.isHeartbeat()) {
DefaultFuture.received(channel, response);
}
}
public void received(Channel channel, Object message) throws RemotingException {
......
if (message instanceof Response) {
handleResponse(channel, (Response) message);
}
......
}
DefaultFuture根據ID擷取Future,通知調用線程
public static void received(Channel channel, Response response) {
......
DefaultFuture future = FUTURES.remove(response.getId());
if (future != null) {
future.doReceived(response);
}
......
}
至此,主線程擷取了傳回資料,調用結束。
三、影響上述流程的關鍵參數
協定參數
我們在使用Dubbo時,需要在服務端配置協定,例如
<dubbo:protocol name="dubbo" port="20880" dispatcher="all" threadpool="fixed" threads="2000" />
下面是協定中與性能相關的一些參數,在我們的使用場景中,線程池選用了fixed,大小是500,隊列為0,其他都是預設值。
服務參數
針對每個Dubbo服務,都會有一個配置,全部的參數配置在這:
http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-service.html。
我們關注幾個與性能相關的。在我們的使用場景中,重試次數設定成了0,叢集方式用的failfast,其他是預設值。
這次擁堵的主要原因,應該就是服務的connections設定的太小,dubbo不提供全局的連接配接數配置,隻能針對某一個交易做個性化的連接配接數配置。
四、連接配接數與Socket緩沖區對性能影響的實驗
通過簡單的Dubbo服務,驗證一下連接配接數與緩沖區大小對傳輸性能的影響。
我們可以通過修改系統參數,調節TCP緩沖區的大小。
在 /etc/sysctl.conf 修改如下内容, tcp_rmem是發送緩沖區,tcp_wmem是接收緩沖區,三個數值表示最小值,預設值和最大值,我們可以都設定成一樣。
net.ipv4.tcp_rmem = 4096 873800 16777216
net.ipv4.tcp_wmem = 4096 873800 16777216
然後執行sysctl –p 使之生效。
服務端代碼如下,接受一個封包,然後傳回兩倍的封包長度,随機sleep 0-300ms,是以均值應該是150ms。服務端每10s列印一次tps和響應時間,這裡的tps是指完成函數調用的tps,而不涉及傳輸,響應時間也是這個函數的時間。
//服務端實作
public String sayHello(String name) {
counter.getAndIncrement();
long start = System.currentTimeMillis();
try {
Thread.sleep(rand.nextInt(300));
} catch (InterruptedException e) {
}
String result = "Hello " + name + name + ", response form provider: " + RpcContext.getContext().getLocalAddress();
long end = System.currentTimeMillis();
timer.getAndAdd(end-start);
return result;
}
用戶端起N個線程,每個線程不停的調用Dubbo服務,每10s列印一次qps和響應時間,這個qps和響應時間是包含了網絡傳輸時間的。
for(int i = 0; i < N; i ++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
while(true) {
Long start = System.currentTimeMillis();
String hello = service.sayHello(z);
Long end = System.currentTimeMillis();
totalTime.getAndAdd(end-start);
counter.getAndIncrement();
}
}});
threads[i].start();
}
通過ss -it指令可以看目前tcp socket的詳細資訊,包含待對端回複ack的資料Send-Q,最大視窗cwnd,rtt(round trip time)等。
(base) niuxinli@ubuntu:~$ ss -it
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 36 192.168.1.7:ssh 192.168.1.4:58931
cubic wscale:8,2 rto:236 rtt:33.837/8.625 ato:40 mss:1460 pmtu:1500 rcvmss:1460 advmss:1460 cwnd:10 bytes_acked:559805 bytes_received:54694 segs_out:2754 segs_in:2971 data_segs_out:2299 data_segs_in:1398 send 3.5Mbps pacing_rate 6.9Mbps delivery_rate 44.8Mbps busy:36820ms unacked:1 rcv_rtt:513649 rcv_space:16130 rcv_ssthresh:14924 minrtt:0.112
ESTAB 0 0 192.168.1.7:36666 192.168.1.7:2181
cubic wscale:7,7 rto:204 rtt:0.273/0.04 ato:40 mss:33344 pmtu:65535 rcvmss:536 advmss:65483 cwnd:10 bytes_acked:2781 bytes_received:3941 segs_out:332 segs_in:170 data_segs_out:165 data_segs_in:165 send 9771.1Mbps lastsnd:4960 lastrcv:4960 lastack:4960 pacing_rate 19497.6Mbps delivery_rate 7621.5Mbps app_limited busy:60ms rcv_space:65535 rcv_ssthresh:66607 minrtt:0.035
ESTAB 0 27474 192.168.1.7:20880 192.168.1.5:60760
cubic wscale:7,7 rto:204 rtt:1.277/0.239 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:625 ssthresh:20 bytes_acked:96432644704 bytes_received:49286576300 segs_out:68505947 segs_in:36666870 data_segs_out:67058676 data_segs_in:35833689 send 5669.5Mbps pacing_rate 6801.4Mbps delivery_rate 627.4Mbps app_limited busy:1340536ms rwnd_limited:400372ms(29.9%) sndbuf_limited:433724ms(32.4%) unacked:70 retrans:0/5 rcv_rtt:1.308 rcv_space:336692 rcv_ssthresh:2095692 notsent:6638 minrtt:0.097
通過netstat -nat也能檢視目前tcp socket的一些資訊,比如Recv-Q, Send-Q。
(base) niuxinli@ubuntu:~$ netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:20880 0.0.0.0:* LISTEN
tcp 0 36 192.168.1.7:22 192.168.1.4:58931 ESTABLISHED
tcp 0 0 192.168.1.7:36666 192.168.1.7:2181 ESTABLISHED
tcp 0 65160 192.168.1.7:20880 192.168.1.5:60760 ESTABLISHED
可以看以下Recv-Q和Send-Q的具體含義:
Recv-Q
Established: The count of bytes not copied by the user program connected to this socket.
Send-Q
Established: The count of bytes not acknowledged by the remote host.
Recv-Q是已經到了接受緩沖區,但是還沒被應用代碼讀走的資料。Send-Q是已經到了發送緩沖區,但是對方還沒有回複Ack的資料。這兩種資料正常一般不會堆積,如果堆積了,可能就有問題了。
第一組實驗:單連接配接,改變TCP緩沖區
結果:
繼續調大緩沖區
我們用netstat或者ss指令可以看到目前的socket情況,下面的第二列是Send-Q大小,是寫入緩沖區還沒有被對端确認的資料,發送緩沖區最大時64k左右,說明緩沖區不夠用。
繼續增大緩沖區,到4M,我們可以看到,響應時間進一步下降,但是還是在傳輸上浪費了不少時間,因為服務端應用層沒有壓力。
服務端和用戶端的TCP情況如下,緩沖區都沒有滿
服務端
用戶端
這個時候,再怎麼調大TCP緩沖區,也是沒用的,因為瓶頸不在這了,而在于連接配接數。因為在Dubbo中,一個連接配接會綁定到一個NioWorker線程上,讀寫都由這一個連接配接完成,傳輸的速度超過了單個線程的讀寫能力,是以我們看到在用戶端,大量的資料擠壓在接收緩沖區,沒被讀走,這樣對端的傳輸速率也會慢下來。
第二組實驗:多連接配接,固定緩沖區
服務端的純業務函數響應時間很穩定,在緩沖區較小的時候,調大連接配接數雖然能讓時間降下來,但是并不能到最優,是以緩沖區不能設定太小,Linux一般預設是4M,在4M的時候,4個連接配接基本上已經能把響應時間降到最低了。
結論
要想充分利用網絡帶寬, 緩沖區不能太小,如果太小有可能一次傳輸的封包就大于了緩沖區,嚴重影響傳輸效率。但是太大了也沒有用,還需要多個連接配接數才能夠充分利用CPU資源,連接配接數起碼要超過CPU核數。