一次Dubbo擁堵的分析
文章內容結構
第一部分介紹生產上出現Dubbo服務擁堵的狀況，以及Dubbo官方對於單個長鏈接的使用建議。html
第二部分介紹Dubbo在特定配置下的通訊過程，輔以代碼。java
第三部分介紹整個調用過程當中與性能相關的一些參數。apache
第四部分經過調整鏈接數和TCP緩衝區觀察Dubbo的性能。json
1、背景
生產擁堵回顧
近期在一次生產發佈過程當中，由於突發的流量，出現了擁堵。系統的部署圖以下，客戶端經過Http協議訪問到Dubbo的消費者，消費者經過Dubbo協議訪問服務提供者。這是單個機房，8個消費者3個提供者，共兩個機房對外服務。ubuntu
在發佈的過程當中，摘掉一個機房，讓另外一個機房對外服務，而後摘掉的機房發佈新版本，而後再互換，最終兩個機房都以新版本對外服務。問題就出現單機房對外服務的時候，這時候單機房仍是老版本應用。之前不知道晚上會有一個高峯，結果當晚的高峯和早上的高峯差很少了，單機房扛不住這麼大的流量，出現了擁堵。這些流量的特色是併發比較高，個別交易返回報文較大，由於是一個產品列表頁，點擊後會發送多個交易到後臺。服務器
在問題發生時，由於不清楚狀態，先切到另一個機房，結果也擁堵了，最後總體回退，折騰了一段時間沒有問題了。當時有一些現象：網絡
(1)提供者的CPU內存等都不高，第一個機房的最高CPU 66%(8核虛擬機)，第二個機房的最高CPU 40%(16核虛擬機)。消費者的最高CPU只有30%多(兩個消費者結點位於同一臺虛擬機上)併發
(2)在擁堵的時候，服務提供者的Dubbo業務線程池(下面會詳細介紹這個線程池)並沒滿，最多到了300，最大值是500。可是把這個機房摘下後，也就是沒有外部的流量了，線程池反而滿了，並且好幾分鐘才把堆積的請求處理完。app
(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協議和一些實驗來驗證咱們的猜想。
2、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);
}
......
}
至此，主線程獲取了返回數據，調用結束。
3、影響上述流程的關鍵參數
協議參數
咱們在使用Dubbo時，須要在服務端配置協議，例如
<dubbo:protocol name="dubbo" port="20880" dispatcher="all" threadpool="fixed" threads="2000" />
下面是協議中與性能相關的一些參數，在咱們的使用場景中，線程池選用了fixed，大小是500，隊列爲0，其餘都是默認值。
| 屬性 | 對應URL參數 | 類型 | 是否必填 | 缺省值 | 做用 | 描述 |
|---|---|---|---|---|---|---|
| name | <protocol> | string | 必填 | dubbo | 性能調優 | 協議名稱 |
| threadpool | threadpool | string | 可選 | fixed | 性能調優 | 線程池類型，可選：fixed/cached。 |
| threads | threads | int | 可選 | 200 | 性能調優 | 服務線程池大小(固定大小) |
| queues | queues | int | 可選 | 0 | 性能調優 | 線程池隊列大小，當線程池滿時，排隊等待執行的隊列大小，建議不要設置，當線程池滿時應當即失敗，重試其它服務提供機器，而不是排隊，除非有特殊需求。 |
| iothreads | iothreads | int | 可選 | cpu個數+1 | 性能調優 | io線程池大小(固定大小) |
| accepts | accepts | int | 可選 | 0 | 性能調優 | 服務提供方最大可接受鏈接數，這個是整個服務端能夠建的最大鏈接數，好比設置成2000，若是已經創建了2000個鏈接，新來的會被拒絕，是爲了保護服務提供方。 |
| dispatcher | dispatcher | string | 可選 | dubbo協議缺省爲all | 性能調優 | 協議的消息派發方式，用於指定線程模型，好比：dubbo協議的all, direct, message, execution, connection等。 這個主要牽涉到IO線程池和業務線程池的分工問題，通常狀況下，讓業務線程池處理創建鏈接、心跳等，不會有太大影響。 |
| payload | payload | int | 可選 | 8388608(=8M) | 性能調優 | 請求及響應數據包大小限制，單位：字節。 這個是單個報文容許的最大長度，Dubbo不適合報文很長的請求，因此加了限制。 |
| buffer | buffer | int | 可選 | 8192 | 性能調優 | 網絡讀寫緩衝區大小。注意這個不是TCP緩衝區，這個是在讀寫網絡報文時，應用層的Buffer。 |
| codec | codec | string | 可選 | dubbo | 性能調優 | 協議編碼方式 |
| serialization | serialization | string | 可選 | dubbo協議缺省爲hessian2，rmi協議缺省爲java，http協議缺省爲json | 性能調優 | 協議序列化方式，當協議支持多種序列化方式時使用，好比：dubbo協議的dubbo,hessian2,java,compactedjava，以及http協議的json等 |
| transporter | transporter | string | 可選 | dubbo協議缺省爲netty | 性能調優 | 協議的服務端和客戶端實現類型，好比：dubbo協議的mina,netty等，能夠分拆爲server和client配置 |
| server | server | string | 可選 | dubbo協議缺省爲netty，http協議缺省爲servlet | 性能調優 | 協議的服務器端實現類型，好比：dubbo協議的mina,netty等，http協議的jetty,servlet等 |
| client | client | string | 可選 | dubbo協議缺省爲netty | 性能調優 | 協議的客戶端實現類型，好比：dubbo協議的mina,netty等 |
| charset | charset | string | 可選 | UTF-8 | 性能調優 | 序列化編碼 |
| heartbeat | heartbeat | int | 可選 | 0 | 性能調優 | 心跳間隔，對於長鏈接，當物理層斷開時，好比拔網線，TCP的FIN消息來不及發送，對方收不到斷開事件，此時須要心跳來幫助檢查鏈接是否已斷開 |
服務參數
針對每一個Dubbo服務，都會有一個配置，所有的參數配置在這：http://dubbo.apache.org/zh-cn/docs/user/references/xml/dubbo-service.html。
咱們關注幾個與性能相關的。在咱們的使用場景中，重試次數設置成了0，集羣方式用的failfast，其餘是默認值。
| 屬性 | 對應URL參數 | 類型 | 是否必填 | 缺省值 | 做用 | 描述 | 兼容性 |
|---|---|---|---|---|---|---|---|
| delay | delay | int | 可選 | 0 | 性能調優 | 延遲註冊服務時間(毫秒) ，設爲-1時，表示延遲到Spring容器初始化完成時暴露服務 | 1.0.14以上版本 |
| timeout | timeout | int | 可選 | 1000 | 性能調優 | 遠程服務調用超時時間(毫秒) | 2.0.0以上版本 |
| retries | retries | int | 可選 | 2 | 性能調優 | 遠程服務調用重試次數，不包括第一次調用，不須要重試請設爲0 | 2.0.0以上版本 |
| connections | connections | int | 可選 | 1 | 性能調優 | 對每一個提供者的最大鏈接數，rmi、http、hessian等短鏈接協議表示限制鏈接數，dubbo等長鏈接協表示創建的長鏈接個數 | 2.0.0以上版本 |
| loadbalance | loadbalance | string | 可選 | random | 性能調優 | 負載均衡策略，可選值：random,roundrobin,leastactive，分別表示：隨機，輪詢，最少活躍調用 | 2.0.0以上版本 |
| async | async | boolean | 可選 | false | 性能調優 | 是否缺省異步執行，不可靠異步，只是忽略返回值，不阻塞執行線程 | 2.0.0以上版本 |
| weight | weight | int | 可選 | 性能調優 | 服務權重 | 2.0.5以上版本 | |
| executes | executes | int | 可選 | 0 | 性能調優 | 服務提供者每服務每方法最大可並行執行請求數 | 2.0.5以上版本 |
| proxy | proxy | string | 可選 | javassist | 性能調優 | 生成動態代理方式，可選：jdk/javassist | 2.0.5以上版本 |
| cluster | cluster | string | 可選 | failover | 性能調優 | 集羣方式，可選：failover/failfast/failsafe/failback/forking | 2.0.5以上版本 |
此次擁堵的主要緣由，應該就是服務的connections設置的過小，dubbo不提供全局的鏈接數配置，只能針對某一個交易作個性化的鏈接數配置。
4、鏈接數與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緩衝區
結果：
| 角色 | Socket緩衝區 | 響應時間 | |
|---|---|---|---|
| 服務端 | 32k/32k | 150ms | |
| 客戶端(800併發) | 32k/32k | 430ms | |
| 客戶端(1併發) | 32k/32k | 150ms |
繼續調大緩衝區
| 角色 | Socket緩衝區 | 響應時間 | CPU |
|---|---|---|---|
| 服務端 | 64k/64k | 150ms | user 2%, sys 9% |
| 客戶端(800併發) | 64k/64k | 275ms | user 4%, sys 13% |
| 客戶端(1併發) | 64k/64k | 150ms | user 4%, sys 13% |
咱們用netstat或者ss命令能夠看到當前的socket狀況，下面的第二列是Send-Q大小，是寫入緩衝區尚未被對端確認的數據，發送緩衝區最大時64k左右，說明緩衝區不夠用。
繼續增大緩衝區，到4M，咱們能夠看到，響應時間進一步降低，可是仍是在傳輸上浪費了很多時間，由於服務端應用層沒有壓力。
| 角色 | Socket緩衝區 | 響應時間 | CPU |
|---|---|---|---|
| 服務端 | 4M/4M | 150ms | user 4%, sys 10% |
| 客戶端(800併發) | 4M/4M | 210ms | user 10%, sys 12% |
| 客戶端(1併發) | 4M/4M | 150ms | user 10%, sys 12% |
服務端和客戶端的TCP狀況以下，緩衝區都沒有滿
<center>服務端</center>
<center>客戶端</center>
這個時候，再怎麼調大TCP緩衝區，也是沒用的，由於瓶頸不在這了，而在於鏈接數。由於在Dubbo中，一個鏈接會綁定到一個NioWorker線程上，讀寫都由這一個鏈接完成，傳輸的速度超過了單個線程的讀寫能力，因此咱們看到在客戶端，大量的數據擠壓在接收緩衝區，沒被讀走，這樣對端的傳輸速率也會慢下來。
第二組實驗：多鏈接，固定緩衝區
服務端的純業務函數響應時間很穩定，在緩衝區較小的時候，調大鏈接數雖然能讓時間降下來，可是並不能到最優，因此緩衝區不能設置過小，Linux通常默認是4M，在4M的時候，4個鏈接基本上已經能把響應時間降到最低了。
| 角色 | Socket緩衝區 | 響應時間 |
|---|---|---|
| 服務端 | 32k/32k | 150ms |
| 客戶端(800併發,1鏈接) | 32k/32k | 430ms |
| 客戶端(800併發,2鏈接) | 32k/32k | 205ms |
| 客戶端(800併發,4鏈接) | 32k/32k | 160ms |
| 客戶端(800併發,6鏈接) | 32k/32k | 156ms |
| 客戶端(800併發,8鏈接) | 32k/32k | 156ms |
| 客戶端(800併發,2鏈接) | 1M/1M | 156ms |
| 客戶端(800併發,2鏈接) | 4M/4M | 156ms |
| 客戶端(800併發,4鏈接) | 4M/4M | 151ms |
| 客戶端(800併發,6鏈接) | 4M/4M | 151ms |
結論
要想充分利用網絡帶寬， 緩衝區不能過小，若是過小有可能一次傳輸的報文就大於了緩衝區，嚴重影響傳輸效率。可是太大了也沒有用，還須要多個鏈接數纔可以充分利用CPU資源，鏈接數起碼要超過CPU核數。
- 1. dubbo的一次請求源碼分析
- 2. TCP的擁堵控制
- 3. 基於決策樹的交通擁堵成因分析
- 4. Dubbo分析一
- 5. TCP網絡擁堵算法
- 6. TCP擁堵控制原理
- 7. dubbo源碼分析一：整體分析
- 8. dubbo源碼分析一：總體分析
- 9. dubbo源碼分析（一）
- 10. 真*dubbo 源碼分析(一)
- 更多相關文章...
- • 高併發系統的分析和設計 - 紅包項目實戰
- • Hibernate的一級緩存 - Hibernate教程
- • 互聯網組織的未來：剖析GitHub員工的任性之源
- • 常用的分佈式事務解決方案
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 外部其他進程嵌入到qt FindWindow獲得窗口句柄 報錯無法鏈接的外部符號 [email protected] 無法被([email protected]@[email protected]@@引用
- 2. UVa 11524 - InCircle
- 3. The Monocycle（bfs）
- 4. VEC-C滑窗
- 5. 堆排序的應用-TOPK問題
- 6. 實例演示ElasticSearch索引查詢term,match,match_phase,query_string之間的區別
- 7. 數學基礎知識 集合
- 8. amazeUI 復擇框問題解決
- 9. 揹包問題理解
- 10. 算數平均-幾何平均不等式的證明,從麥克勞林到柯西
- 1. dubbo的一次請求源碼分析
- 2. TCP的擁堵控制
- 3. 基於決策樹的交通擁堵成因分析
- 4. Dubbo分析一
- 5. TCP網絡擁堵算法
- 6. TCP擁堵控制原理
- 7. dubbo源碼分析一：整體分析
- 8. dubbo源碼分析一：總體分析
- 9. dubbo源碼分析（一）
- 10. 真*dubbo 源碼分析(一)